[Catalyst] Fastest Perl HTTPD?

[Matt S Trout]

Perrin Harkins wrote:
> Len Jaffe wrote:
>> Isn't that the whole point of this architecture.
>>
>> The lightweight daemon that listens on port 80 either serves static 
>> content,
>> or asks the heavy app server process to do some work.
>>
>> That way you have a whole bunch of light processes serving the static 
>> stuff,
>> and fewer heavy processes.  Once the heavy process is done, and hands it's
>> output back to the light process, it is free to work for another light
>> process, while the first light process deals with network transfer back to
>> the client.
> 
> Actually you have one light process doing non-blocking I/O and serving 
> all of the static stuff and a bunch of heavy processes doing all of the 
> dynamic stuff.  That's what you already have when you use 
> Lighttpd/apache with FastCGI or apache/squid as a reverse proxy to a 
> separate mod_perl process.  The non-blocking I/O server may be faster 
> for the static stuff than apache is, but apache is already so fast at 
> static stuff that it won't matter much unless you're using an old 
> under-powered machine.
> 
> In other words, you can't speed up any of the dynamic stuff using Matt's 
> new non-blocking server unless you can figure out a way for it to deal 
> with DBI (and any other blocking I/O) that is more efficient than just 
> passing off requests to FastCGI/mod_perl processes.

Sure, but I'll happily take "not any faster" or even "slightly slower" in 
return for having a front-end server that's written in perl so I can do 
arbitrary hackery in the httpd with my language of choice if I need to.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +