perl-advocacy mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Moyer <>
Subject Re: FastCGI, mod_perl, catalyst
Date Sun, 09 Dec 2007 04:50:48 GMT
Adam Prime wrote:
> I realize this list has been completely dead for a year now, but i'll 
> give this a shot anyway.  I saw this today.
> And I wondered if anyone might want to address the comment 'mod_perl is 
> bloated'.  I'm sure it's 'bloated' compared to FastCGI, but FastCGI and 
> mod_perl are barely comparable.

Where there is smoke, there is fire.  But watch out for the mirrors.

Interesting that his cookbook link leads to this:

   mod_perl Deployment

   mod_perl is the best solution for many applications, but we'll list
   some pros and cons so you can decide for yourself. The other
   production deployment option is FastCGI, for which see below.

There was some concern at ApacheCon that the mod_perl core is difficult 
to maintain because it is mostly written in XS.  One person suggested 
that a thin wrapper around the Apache API would be a logical next step. 
  There is a performance hit to that approach, but the maintainability 
of the core would likely go up.

I think that a lot of times when FastCGI is compared to mod_perl it 
really needs to be compared to ModPerl::Registry and Apache::PerlRun, 
Gozer gave a talk about this at Apachecon, and the room was packed. 
Those are the people trying to decide between mod_perl and fast_cgi.

I think that  ModPerl::Registry should split off from the core, and be 
independent like Apache::Reload is in the process of doing.  That's a 
dev topic though and I'll leave that to the dev list.

   But you can read the comment i've
> already left yourself.
> Adam
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message