You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Bas <ba...@integrators.demon.nl> on 2000/07/05 23:15:37 UTC
Coldfusion vs. apache/mod_perl
Hi all,
this is probably gonna be a longish one. It's about coldfusion vs. the
combination of apache/mod_perl, I'm hoping to find some people on the list
who have some experience with both, and who maybe faced a similar question.
I've been searching the Net for a few days now to find opinions, but espec.
in comparison to the apache/mod_perl combo, I couldn't find that much.
Some intro: I work for a content syndication company; basically, we receive
tons of different newsfeeds, we classify the content, both manually as well
as automatically (based on fulltext and metadata queries), we add some extra
content if it's not in the incoming data (for instance, we create a smaller
version of a news story so it reads better on a WAP device), then we have
quite a bit of distribution options: we do HTML, plain text, XML, using
transports such as FTP, e-mail, HTTP Post, as well as host the news which
customers can include dynamically in their website.
The parts that involve website development are currently done exclusively
using apache and mod_perl, this makes up about 35% of our overall system.
Now, it seems that Allaire's product, Spectra, does offer us a solution to
(parts of) our problems. I'm not sure yet exactly what problem it solves, we
still have to establish that, but let's assume it does. Spectra is a product
built using Allaire's ColdFusion. That means that if we have to add
functionality to Spectra, we'll be using coldfusion to develop that.
To assess coldfusion, I installed the eval version on one of our Linux boxes
to explore it.
Here are some of my observations:
1- "Code inside HTML"
coldfusion's like PHP or ASP in that you embed most of your code inside HTML
pages.
I don't like it; I prefer to use some templating system that allows our HTML
wizards to edit HTML, and our perl wizards to code perl.
But let's not start that discussion: we've seen it before ;)
2- Feature comparison
If I compary the features available in the coldfusion appserver with the
available options for mod_perl, I don't see a lot of extra's:
- session management
We do that using our own Web::Session implementation (very much like
Apache::Session). It can do that either using cookies or stick the session
id in the URL. coldfusion seems to require cookies.
- database connection pooling
We use Apache::DBI;
- Scheduled tasks
We use cron;
- Sending mail from within the appserver
Tons of CPAN modules can do this. Great MIME stuff there too;
- Retrieve web page and stick into local file
This is a built-in feature of the appserver. lwp-mirror can do this just
fine.
- coldfusion can use COM (or is that ActiveX?)
Apparently, there are a lot of those thingies to stick into coldfusion and
use that from within your code.
We run HP-UX; those won't work for us.
- coldfusion can be clustered (apparently automagically)
So far I haven't had the need to do this; our HP box with 4 processors never
gets a load above 0.2.
I assume with Apache running on a few boxes, some load-balancing hardware in
front of those, and some URL rewriting and/or smarter session management,
clustering could be accomplished as well. I doubt we need this though. If we
do high volume content serving, I'll convert the dynamic content to static
html or xml, ftp them over to a box running a non-mod_perl Apache and serve
'm from there. I never measured this too well, I think it did something like
400 reqs/second on Intel hardware running Linux.
3- Complexity of layers (or would those be called 'tiers'?)
With mod_perl, I have to make sure Apache runs (Ok; I need to get the stuff
compiled too. I can do that. By now ;)), so far, I haven't seen Apache go
down ever. With coldfusion, aside from Apache, I have to make sure a
bunchful of different coldfusion apps are running. How stable are those
apps?
Also, I don't know how coldfusion talks to Oracle. DBI/DBD::Oracle works
good enough.
4- Developer community
Concluding from the amount of hits I got searching dejanews etc., the
coldfusion developer community is hiding out somewhere else. On Allaire's
site, success stories sound great; mod_perl's success stories on
perl.apache.org do too, but they don't contain a lot of buzzwords (;)
).
I'd love to hear some opinions on this. I'm not looking for "stick to what
you know"-kinda replies; I know that already. It's just that *if* Spectra
does provide needed functionality, it will be faster to buy it than it is to
develop the same functionality using apache/mod_perl. Yet, I do want to know
what I'll be getting into when I need to work with coldfusion on a daily
basis vs. working with apache/mod_perl on a daily basis.
Regards,
bas.
Re: R. Berjon's Mod_perl site (was "Re: Coldfusion vs.
apache/mod_perl")
Posted by brian moseley <ix...@maz.org>.
On Fri, 7 Jul 2000, Robin Berjon wrote:
> No need to apologize, we've all got a lot to do. Is it
> just a matter of committing the cvs or is there more to
> be done ? I have a little bit of time between now and
> the middle of the month, I can help if need be.
jim took a snapshot of a subset of the site and applied his
changes to it. i need to incorporate changes that have been
made since the snapshot, and apply the template to the rest
of the site. it'll be a fair amount of work, but perhaps i
can do it in chunks, and i'll certainly commit the template,
so perhaps folks can help with that part.
Re: R. Berjon's Mod_perl site (was "Re: Coldfusion vs.
apache/mod_perl")
Posted by Robin Berjon <ro...@knowscape.com>.
At 21:12 06/07/2000 -0700, brian moseley wrote:
>On Thu, 6 Jul 2000, Robin Berjon wrote:
>
>> I think the new site was about to be committed but I
>> don't know what happened with that. One recent
>
>my apologies. i've been meaning to do it, but real life has
>gotten in the way. i'll have it done by the end of the
>weekend.
No need to apologize, we've all got a lot to do. Is it just a matter of
committing the cvs or is there more to be done ? I have a little bit of
time between now and the middle of the month, I can help if need be.
>> suggestion likely to make people happier in the graphicy
>> vs developery thing would be to have
>> developer.modperl.org for developers and www.modperl.org
>> for advocacy. I'm ready to do some work on this this
>> summer if there is stuff to be done.
>
>i really like this idea. a lot.
Me too, the only hindrance I see is that it would probably take writing
some of the advocacy stuff, which could take time.
>i suppose, but i still like to hear people's opinions, and
>nobody really ever discusses anything on advocacy.
I don't really care, it's just in case people don't want to hear about this :)
-- robin b.
All paid jobs absorb and degrade the mind. -- Aristotle
Re: R. Berjon's Mod_perl site (was "Re: Coldfusion vs. apache/mod_perl")
Posted by brian moseley <ix...@maz.org>.
On Thu, 6 Jul 2000, Robin Berjon wrote:
> I think the new site was about to be committed but I
> don't know what happened with that. One recent
my apologies. i've been meaning to do it, but real life has
gotten in the way. i'll have it done by the end of the
weekend.
> suggestion likely to make people happier in the graphicy
> vs developery thing would be to have
> developer.modperl.org for developers and www.modperl.org
> for advocacy. I'm ready to do some work on this this
> summer if there is stuff to be done.
i really like this idea. a lot.
> PS: Discussion of such things would be better suited for
> advocacy@perl.apache.org I guess.
i suppose, but i still like to hear people's opinions, and
nobody really ever discusses anything on advocacy.
Re: R. Berjon's Mod_perl site (was "Re: Coldfusion vs.
apache/mod_perl")
Posted by Robin Berjon <ro...@knowscape.com>.
At 09:15 07/07/2000 +0800, Gunther Birznieks wrote:
>At 08:36 AM 7/6/00 -0700, Graham TerMarsch wrote:
>>Matt Sergeant wrote:
>> > Well of course AxKit gives me the consistent layout, and Robin Berjon gave
>> > me the design. He also did a perl.apache.org one, but people didn't like
>> > it - said it was too graphicy or something. Thats at
>> > http://www.knowscape.org/modperl/
>>
>>Is too bad, I think this one looks really _slick_. It'd get my vote.
>
>Even if some don't think it's perfect, it's certainly better than the one
>now I would think?
I don't know where things are at re the refacing of the perl.apache.org
website. Part of it not happening before has been my fault for being caught
up to the neck in work and not taking care of it.
I think the new site was about to be committed but I don't know what
happened with that. One recent suggestion likely to make people happier in
the graphicy vs developery thing would be to have developer.modperl.org for
developers and www.modperl.org for advocacy. I'm ready to do some work on
this this summer if there is stuff to be done.
PS: Discussion of such things would be better suited for
advocacy@perl.apache.org I guess.
-- robin b.
Immature poets imitate, mature poets steal. -- T.S. Eliot
Re: R. Berjon's Mod_perl site (was "Re: Coldfusion vs.
apache/mod_perl")
Posted by Gunther Birznieks <gu...@extropia.com>.
At 08:36 AM 7/6/00 -0700, Graham TerMarsch wrote:
>Matt Sergeant wrote:
> > Well of course AxKit gives me the consistent layout, and Robin Berjon gave
> > me the design. He also did a perl.apache.org one, but people didn't like
> > it - said it was too graphicy or something. Thats at
> > http://www.knowscape.org/modperl/
>
>Is too bad, I think this one looks really _slick_. It'd get my vote.
Even if some don't think it's perfect, it's certainly better than the one
now I would think?
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
R. Berjon's Mod_perl site (was "Re: Coldfusion vs. apache/mod_perl")
Posted by Graham TerMarsch <gr...@howlingfrog.com>.
Matt Sergeant wrote:
> Well of course AxKit gives me the consistent layout, and Robin Berjon gave
> me the design. He also did a perl.apache.org one, but people didn't like
> it - said it was too graphicy or something. Thats at
> http://www.knowscape.org/modperl/
Is too bad, I think this one looks really _slick_. It'd get my vote.
--
Graham TerMarsch
// -----------------------------------------------------------------
// Ignorance is when you don't know anything and somebody finds it out.
// -----------------------------------------------------------------
Re: Coldfusion vs. apache/mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 6 Jul 2000, Gunther Birznieks wrote:
>
> >
> >Take a look - hopefully you'll be impressed ;-)
> >
> >http://axkit.org/
> >
> >BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October.
>
> Holy s..t! this is a well-laid out site!! Could you do the same for
> perl.apache.org? :)
Well of course AxKit gives me the consistent layout, and Robin Berjon gave
me the design. He also did a perl.apache.org one, but people didn't like
it - said it was too graphicy or something. Thats at
http://www.knowscape.org/modperl/
It would be cool if perl.apache.org were to run AxKit ;-)
BTW: My box-out is done using RSS, and is automatically updated. Thought
people might like to know.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: Coldfusion vs. apache/mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 6 Jul 2000, Gunther Birznieks wrote:
>
> >
> >Take a look - hopefully you'll be impressed ;-)
> >
> >http://axkit.org/
> >
> >BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October.
>
> Holy s..t! this is a well-laid out site!! Could you do the same for
> perl.apache.org? :)
>
> BTW, if you are distributing as integration with GPL software, you don't
> have to make your stuff GPL too? Or is that Sablotron actually using the
> lesser/library version of GPL?
Sablotron is MPL/GPL - same as Expat.
But I'm confused over how this whole thing works with AxKit - I mean all
I'm doing is providing a module that can work with Sablotron. You don't
_have_ to use it. So I don't really see how this can affect my work, but
this is one of the really confusing areas of the GPL, and it really needs
an FAQ. (all of this of course has no relevance now that Sablotron can be
distributed under the MPL).
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: Coldfusion vs. apache/mod_perl
Posted by Gunther Birznieks <gu...@extropia.com>.
>
>Take a look - hopefully you'll be impressed ;-)
>
>http://axkit.org/
>
>BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October.
Holy s..t! this is a well-laid out site!! Could you do the same for
perl.apache.org? :)
BTW, if you are distributing as integration with GPL software, you don't
have to make your stuff GPL too? Or is that Sablotron actually using the
lesser/library version of GPL?
I seem to recall that now that mySQL has switched to GPL, they have all
sorts of alternative licensing stuff on their website because GPL is so tough.
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: Coldfusion vs. apache/mod_perl
Posted by Joshua Chamas <jo...@chamas.com>.
Paul Lindner wrote:
>
> > Hey Paul,
> >
> > I think you will have a problem with cold fusion templating
> > logic like if/else constructs. For these, I would recommend
> > having something like a ColdFusionCompat config setting, and we
> > could rip out some of these are parse time and convert them into the
> > ASP style constructs.
>
> One idea is to have a separate class of tags that are used in the
> parse stage.:
>
> CodeTags (cfif|cfelse|cfend)
>
> sub cfend {
> return('}');
> }
>
> sub cfelse {
> return('} else {');
> }
>
It would be nice to have this extension, I can see why,
so instead of executing the XMLSubs at runtime, they
would be executed at compile time, which would prevent
them from being defined in the script itself being
compiled. Have to be in global.asa or some perllib.
Note that in global.asa, there could be the likes of
*cfend = *CF::Tags::end;
*cfelse = *CF::Tags::else;
So, how would a XMLParseSubsMatch config be for this
behavior?
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
Re: Coldfusion vs. apache/mod_perl
Posted by Chris Fry <ch...@quillsoft.com.au>.
Anyone looked at PHP???
Paul Lindner wrote:
> On Wed, Jul 05, 2000 at 04:09:06PM -0700, Joshua Chamas wrote:
> > Paul Lindner wrote:
> > >
> > > > IMHO, mod_perl applications easily out-performed our CF apps.
> > > >
> > > > One plus for coldfusion, there seems to be more CF developers out there (at
> > > > least in Austin, TX) but that may be a sign that very few people are using CF.
> > > >
> > > > My opinion: stick to mod_perl, it won't let you down.
> > >
> > > I've been toying with using the Apache::ASP custom tag feature to
> > > support cold-fusion like applications. I don't think it will be too
> > > hard; reading the spec it appears you need to make a list of named
> > > queries and then use <cfoutput> tags with #fieldname# entries.
> > >
> > > This is absurdly simple with Joshua's new Apache::ASP. Just define
> > > cfoutput as a custom tag, and write a small handler for it.
> > >
> > > I'll have to look up the other tags they support, but they shouldn't
> > > be too hard to implement...
> > >
> > > Has anyone else out there wrote their own cold-fusion routines?
> > >
> >
> > Hey Paul,
> >
> > I think you will have a problem with cold fusion templating
> > logic like if/else constructs. For these, I would recommend
> > having something like a ColdFusionCompat config setting, and we
> > could rip out some of these are parse time and convert them into the
> > ASP style constructs.
>
> One idea is to have a separate class of tags that are used in the
> parse stage.:
>
> CodeTags (cfif|cfelse|cfend)
>
> sub cfend {
> return('}');
> }
>
> sub cfelse {
> return('} else {');
> }
>
> sub cfif {
> ..... # heavy lifting here..
> return('if (......) {');
> }
>
> > I am planning to use this approach for support of XSP logic
> > for XML/XSLT integration, and can't see how to use the custom
> > tags for full logic implementations of other environments,
> > particularly the if/else contructs. Might there be some
> > way to extend the XMLSubsMatch technology to coordinate
> > between multiple tags?
> >
> > I think what we need to is something like a Script_OnParse
> > that one could use to grab the script data and parse it
> > before the ASP to perl compiler gets to it. This would
> > allow for some experimentation out of the code base before
> > merging in something big like XSP or ColdFusion support.
>
> That would definitely do the trick too. Though instead I'd use
> various regular expressions to convert tags into ASP syntax..
>
> --
> Paul Lindner
> plindner@redhat.com
> Red Hat Inc.
--
Chris Fry
Quillsoft Pty Ltd
10 Gray Street
Kogarah
NSW 2217
Australia
Phone: +61 2 9553 1691
Fax: +61 2 9553 1692
Mobile: 0419 414 323
eMail: chris@quillsoft.com.au
http://www.quillsoft.com.au
Re: Coldfusion vs. apache/mod_perl
Posted by Paul Lindner <pl...@redhat.com>.
On Wed, Jul 05, 2000 at 04:09:06PM -0700, Joshua Chamas wrote:
> Paul Lindner wrote:
> >
> > > IMHO, mod_perl applications easily out-performed our CF apps.
> > >
> > > One plus for coldfusion, there seems to be more CF developers out there (at
> > > least in Austin, TX) but that may be a sign that very few people are using CF.
> > >
> > > My opinion: stick to mod_perl, it won't let you down.
> >
> > I've been toying with using the Apache::ASP custom tag feature to
> > support cold-fusion like applications. I don't think it will be too
> > hard; reading the spec it appears you need to make a list of named
> > queries and then use <cfoutput> tags with #fieldname# entries.
> >
> > This is absurdly simple with Joshua's new Apache::ASP. Just define
> > cfoutput as a custom tag, and write a small handler for it.
> >
> > I'll have to look up the other tags they support, but they shouldn't
> > be too hard to implement...
> >
> > Has anyone else out there wrote their own cold-fusion routines?
> >
>
> Hey Paul,
>
> I think you will have a problem with cold fusion templating
> logic like if/else constructs. For these, I would recommend
> having something like a ColdFusionCompat config setting, and we
> could rip out some of these are parse time and convert them into the
> ASP style constructs.
One idea is to have a separate class of tags that are used in the
parse stage.:
CodeTags (cfif|cfelse|cfend)
sub cfend {
return('}');
}
sub cfelse {
return('} else {');
}
sub cfif {
..... # heavy lifting here..
return('if (......) {');
}
> I am planning to use this approach for support of XSP logic
> for XML/XSLT integration, and can't see how to use the custom
> tags for full logic implementations of other environments,
> particularly the if/else contructs. Might there be some
> way to extend the XMLSubsMatch technology to coordinate
> between multiple tags?
>
> I think what we need to is something like a Script_OnParse
> that one could use to grab the script data and parse it
> before the ASP to perl compiler gets to it. This would
> allow for some experimentation out of the code base before
> merging in something big like XSP or ColdFusion support.
That would definitely do the trick too. Though instead I'd use
various regular expressions to convert tags into ASP syntax..
--
Paul Lindner
plindner@redhat.com
Red Hat Inc.
Re: Coldfusion vs. apache/mod_perl
Posted by Joshua Chamas <jo...@chamas.com>.
Paul Lindner wrote:
>
> > IMHO, mod_perl applications easily out-performed our CF apps.
> >
> > One plus for coldfusion, there seems to be more CF developers out there (at
> > least in Austin, TX) but that may be a sign that very few people are using CF.
> >
> > My opinion: stick to mod_perl, it won't let you down.
>
> I've been toying with using the Apache::ASP custom tag feature to
> support cold-fusion like applications. I don't think it will be too
> hard; reading the spec it appears you need to make a list of named
> queries and then use <cfoutput> tags with #fieldname# entries.
>
> This is absurdly simple with Joshua's new Apache::ASP. Just define
> cfoutput as a custom tag, and write a small handler for it.
>
> I'll have to look up the other tags they support, but they shouldn't
> be too hard to implement...
>
> Has anyone else out there wrote their own cold-fusion routines?
>
Hey Paul,
I think you will have a problem with cold fusion templating
logic like if/else constructs. For these, I would recommend
having something like a ColdFusionCompat config setting, and we
could rip out some of these are parse time and convert them into the
ASP style constructs.
I am planning to use this approach for support of XSP logic
for XML/XSLT integration, and can't see how to use the custom
tags for full logic implementations of other environments,
particularly the if/else contructs. Might there be some
way to extend the XMLSubsMatch technology to coordinate
between multiple tags?
I think what we need to is something like a Script_OnParse
that one could use to grab the script data and parse it
before the ASP to perl compiler gets to it. This would
allow for some experimentation out of the code base before
merging in something big like XSP or ColdFusion support.
-- Joshua
Re: Coldfusion vs. apache/mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 5 Jul 2000, Paul Lindner wrote:
> I've been toying with using the Apache::ASP custom tag feature to
> support cold-fusion like applications. I don't think it will be too
> hard; reading the spec it appears you need to make a list of named
> queries and then use <cfoutput> tags with #fieldname# entries.
Not to dismiss Joshua's interesting looking extensions to Apache::ASP, but
have you checked out AxKit's SQL taglib stuff?
Here's an XSP to extract rows from a messages table:
<xsp:page
language="Perl"
xmlns:sql="http://www.apache.org/1999/SQL"
xmlns:xsp="http://www.apache.org/1999/XSP/Core"
>
<page title="SQL Search Results">
<sql:execute-query>
<sql:driver>Sybase</sql:driver>
<sql:username>webboard</sql:username>
<sql:password>password</sql:password>
<sql:doc-element>options</sql:doc-element>
<sql:row-element>option</sql:row-element>
<sql:tag-case>lower</sql:tag-case>
<sql:null-indicator>yes</sql:null-indicator>
<sql:id-attribute>ID</sql:id-attribute>
<sql:id-attribute-column>msgid</sql:id-attribute-column>
<sql:query>select * from Messages</sql:query>
<sql:count-attribute>count</sql:count-attribute>
</sql:execute-query>
</page>
</xsp:page>
This is then styled using XSLT in the next part of the pipeline. My box
can deliver 14 hits/sec on this (executed and styled using XSLT on every
hit). Not exactly blazing, but fast enough for a lot of uses.
And don't be put off by the verbosity - all this can be modularised in
external entities and/or taglibs.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: Coldfusion vs. apache/mod_perl
Posted by Paul Lindner <pl...@redhat.com>.
On Wed, Jul 05, 2000 at 04:30:01PM -0500, jbodnar@team-linux.com wrote:
> I just left a company that used either mod_perl or coldfusion for our intranet
> development. I never did any coldfusion development but I did have to deal with
> maintaing the coldfusion server and apps.
>
> coldfusion crashed several times in the three or four months I was involved
> with it. We never could determine what the problem was.
>
> coldfusion (like Apache/mod_perl) eats memory. Our coldfusion processes usually
> used a total of 200MB of memory.
>
> coldfusion does not play well on unix (at least solaris). Allaire's site
> recommended changing some kernel parameters to get the best performance out of
> cold fusion. That was something we weren't willing to do on a box that had much
> more than CF running on it.
>
> To my knowledge, CF does not give you the power to mess with the web servers
> API like mod_perl does. You may or may not need this ability.
>
> IMHO, mod_perl applications easily out-performed our CF apps.
>
> One plus for coldfusion, there seems to be more CF developers out there (at
> least in Austin, TX) but that may be a sign that very few people are using CF.
>
> My opinion: stick to mod_perl, it won't let you down.
I've been toying with using the Apache::ASP custom tag feature to
support cold-fusion like applications. I don't think it will be too
hard; reading the spec it appears you need to make a list of named
queries and then use <cfoutput> tags with #fieldname# entries.
This is absurdly simple with Joshua's new Apache::ASP. Just define
cfoutput as a custom tag, and write a small handler for it.
I'll have to look up the other tags they support, but they shouldn't
be too hard to implement...
Has anyone else out there wrote their own cold-fusion routines?
--
Paul Lindner
plindner@redhat.com
Red Hat Inc.
RE: Coldfusion vs. apache/mod_perl
Posted by jb...@team-linux.com.
I just left a company that used either mod_perl or coldfusion for our intranet
development. I never did any coldfusion development but I did have to deal with
maintaing the coldfusion server and apps.
coldfusion crashed several times in the three or four months I was involved
with it. We never could determine what the problem was.
coldfusion (like Apache/mod_perl) eats memory. Our coldfusion processes usually
used a total of 200MB of memory.
coldfusion does not play well on unix (at least solaris). Allaire's site
recommended changing some kernel parameters to get the best performance out of
cold fusion. That was something we weren't willing to do on a box that had much
more than CF running on it.
To my knowledge, CF does not give you the power to mess with the web servers
API like mod_perl does. You may or may not need this ability.
IMHO, mod_perl applications easily out-performed our CF apps.
One plus for coldfusion, there seems to be more CF developers out there (at
least in Austin, TX) but that may be a sign that very few people are using CF.
My opinion: stick to mod_perl, it won't let you down.
On 05-Jul-2000 Bas wrote:
> Hi all,
>
> this is probably gonna be a longish one. It's about coldfusion vs. the
> combination of apache/mod_perl, I'm hoping to find some people on the list
> who have some experience with both, and who maybe faced a similar question.
> I've been searching the Net for a few days now to find opinions, but espec.
> in comparison to the apache/mod_perl combo, I couldn't find that much.
>
> Some intro: I work for a content syndication company; basically, we receive
> tons of different newsfeeds, we classify the content, both manually as well
> as automatically (based on fulltext and metadata queries), we add some extra
> content if it's not in the incoming data (for instance, we create a smaller
> version of a news story so it reads better on a WAP device), then we have
> quite a bit of distribution options: we do HTML, plain text, XML, using
> transports such as FTP, e-mail, HTTP Post, as well as host the news which
> customers can include dynamically in their website.
>
> The parts that involve website development are currently done exclusively
> using apache and mod_perl, this makes up about 35% of our overall system.
>
> Now, it seems that Allaire's product, Spectra, does offer us a solution to
> (parts of) our problems. I'm not sure yet exactly what problem it solves, we
> still have to establish that, but let's assume it does. Spectra is a product
> built using Allaire's ColdFusion. That means that if we have to add
> functionality to Spectra, we'll be using coldfusion to develop that.
>
> To assess coldfusion, I installed the eval version on one of our Linux boxes
> to explore it.
>
> Here are some of my observations:
>
> 1- "Code inside HTML"
>
> coldfusion's like PHP or ASP in that you embed most of your code inside HTML
> pages.
>
> I don't like it; I prefer to use some templating system that allows our HTML
> wizards to edit HTML, and our perl wizards to code perl.
>
> But let's not start that discussion: we've seen it before ;)
>
>
> 2- Feature comparison
>
> If I compary the features available in the coldfusion appserver with the
> available options for mod_perl, I don't see a lot of extra's:
>
> - session management
>
> We do that using our own Web::Session implementation (very much like
> Apache::Session). It can do that either using cookies or stick the session
> id in the URL. coldfusion seems to require cookies.
>
>
> - database connection pooling
>
> We use Apache::DBI;
>
>
> - Scheduled tasks
>
> We use cron;
>
>
> - Sending mail from within the appserver
>
> Tons of CPAN modules can do this. Great MIME stuff there too;
>
>
> - Retrieve web page and stick into local file
>
> This is a built-in feature of the appserver. lwp-mirror can do this just
> fine.
>
>
> - coldfusion can use COM (or is that ActiveX?)
>
> Apparently, there are a lot of those thingies to stick into coldfusion and
> use that from within your code.
>
> We run HP-UX; those won't work for us.
>
>
> - coldfusion can be clustered (apparently automagically)
>
> So far I haven't had the need to do this; our HP box with 4 processors never
> gets a load above 0.2.
>
> I assume with Apache running on a few boxes, some load-balancing hardware in
> front of those, and some URL rewriting and/or smarter session management,
> clustering could be accomplished as well. I doubt we need this though. If we
> do high volume content serving, I'll convert the dynamic content to static
> html or xml, ftp them over to a box running a non-mod_perl Apache and serve
> 'm from there. I never measured this too well, I think it did something like
> 400 reqs/second on Intel hardware running Linux.
>
>
> 3- Complexity of layers (or would those be called 'tiers'?)
>
> With mod_perl, I have to make sure Apache runs (Ok; I need to get the stuff
> compiled too. I can do that. By now ;)), so far, I haven't seen Apache go
> down ever. With coldfusion, aside from Apache, I have to make sure a
> bunchful of different coldfusion apps are running. How stable are those
> apps?
>
> Also, I don't know how coldfusion talks to Oracle. DBI/DBD::Oracle works
> good enough.
>
>
> 4- Developer community
>
> Concluding from the amount of hits I got searching dejanews etc., the
> coldfusion developer community is hiding out somewhere else. On Allaire's
> site, success stories sound great; mod_perl's success stories on
> perl.apache.org do too, but they don't contain a lot of buzzwords (;)
> ).
>
>
> I'd love to hear some opinions on this. I'm not looking for "stick to what
> you know"-kinda replies; I know that already. It's just that *if* Spectra
> does provide needed functionality, it will be faster to buy it than it is to
> develop the same functionality using apache/mod_perl. Yet, I do want to know
> what I'll be getting into when I need to work with coldfusion on a daily
> basis vs. working with apache/mod_perl on a daily basis.
>
> Regards,
>
> bas.
--
Jason Bodnar + jbodnar@team-linux.com + Team Linux
Okay, Marge, as long as we're traumatizing the kids, I have a scandalous
story of my own.
-- Homer Simpson
Another Simpsons Clip Show
Re: Coldfusion vs. apache/mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 5 Jul 2000, Bas wrote:
> Hi all,
>
> this is probably gonna be a longish one. It's about coldfusion vs. the
> combination of apache/mod_perl, I'm hoping to find some people on the list
> who have some experience with both, and who maybe faced a similar question.
> I've been searching the Net for a few days now to find opinions, but espec.
> in comparison to the apache/mod_perl combo, I couldn't find that much.
>
> Some intro: I work for a content syndication company; basically, we receive
> tons of different newsfeeds, we classify the content, both manually as well
> as automatically (based on fulltext and metadata queries), we add some extra
> content if it's not in the incoming data (for instance, we create a smaller
> version of a news story so it reads better on a WAP device), then we have
> quite a bit of distribution options: we do HTML, plain text, XML, using
> transports such as FTP, e-mail, HTTP Post, as well as host the news which
> customers can include dynamically in their website.
You sound like you need to check out AxKit - it would probably fit your
needs perfectly. Your templating needs are delivered using XSLT or
XPathScript or XMLNews::HTMLTemplate, caching is taken care of, as is
dynamic content (using XSP) and database queries (using the XSP SQL
taglib).
Take a look - hopefully you'll be impressed ;-)
http://axkit.org/
BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org