[Catalyst] Fastest Perl HTTPD?

Pedro Melo melo at simplicidade.org
Mon Aug 28 12:19:26 CEST 2006


Hi,

On 2006/08/26, at 15:50, Matt S Trout wrote:

> Pedro Melo wrote:
>> Hi,
>>
>> On 2006/08/26, at 13:32, Matt S Trout wrote:
>>> Axkit2 looks like it'll be a lovely candidate for a production- 
>>> quality
>>> scalable standalone server, although it's a single-process affair  
>>> with
>>> optional forking so we'll need to figure out how to manage that
>>> appropriately
>>> to maximise performance.
>>
>> hmms... In fact if he forks and supports Keep-Alive, i'll be happy.
>> Usually you already have a front-end reverse proxy for static
>> content, and usually that front-end is able to keep persistent
>> connections to the back-end application servers.
>
> Right, but the whole point of the AIO approach is that it can do  
> the comms
> back to the front-end asynchronously itself - i.e. it already has  
> the key
> thing that makes perlbal/lighty/etc. scalable built into itself. So  
> we want to
> take advantage of that, probably by setting it up so as soon as  
> finalize_body
> is called the response can be handed back to Axkit2 in full and the  
> Catalyst
> process can go on to serving another request.

If you have a Perlbal or lighttpd as a frontend, they are usually  
connected with pretty good bandwidth to the back-end (100Mbits or  
better). So the time you have the Catalyst app idle between the  
sending of the data at full speed and getting a new request doesn't  
seem to me to be a problem.

Besides, if you hide from the perlbal/lighttpd the real status of  
your catalyst core (by having multiple TCP connections from front-end  
to back-end hitting the same instance of catalyst, you run the risk  
of having your front-end sending several request to the same  
instance. As far as he knows, all TCP-to-back-end connections look  
the same in terms of response time.

I like the idea of a Perl-based HTTPd so that we can scrap the  
FastCGI protocol (not meant to be a flame, but HTTP is more powerful  
than FCGI), but I don't think that the back-ends should hide their  
real status behind a TCP multiplexer.

Best regards,
--
Pedro Melo
JID: xmpp:melo at simplicidade.org





More information about the Catalyst mailing list