From: Dan Janowski <danj@3skel.com>
Date: 2005-09-19T22:14:44+09:00
Subject: Re: acgi-0.1.0

Ara,

My applause to you on trying to replace FastCGI. I gave up on it  
after inexplicable weirdness began to set in.

Fork/exec overhead is typically small, and with caching, shared  
libraries, etc. there is likely little to be gained by making your  
index.cgi a module (and penalty a plenty).

Try timing the fifo transit and locking. One way of side stepping the  
fifo limitation is to consider shared memory mapped files (via mmap)  
which are frighteningly fast and cut the kernel transit out all  
together.

Dan

On Sep 17, 2005, at 09:11, Ara.T.Howard wrote:

> On Sat, 17 Sep 2005, Matthias Georgi wrote:
>
>
>> Hi Ara,
>>
>> out of curiosity, I have been playing around with my apache2 setup  
>> and
>> benchmarked cgi, acgi and fcgi. I used this configuration for maximum
>> performance:
>>
>> <IfModule prefork.c>
>> StartServers        100
>> MinSpareServers     100
>> MaxSpareServers     100
>> MaxClients          250
>> MaxRequestsPerChild  50
>> </IfModule>
>>
>
> valuable - thanks for sharing.
>
>
>> Running on my Athlon-2800 I get these results:
>>
>> CGI:
>> # ab -n100 -c10 http://127.0.0.1:8080/env.cgi | grep "Requests per
>> second"
>> Requests per second:    52.00 [#/sec] (mean)
>>
>> ACGI:
>> # ab -n100 -c10 http://127.0.0.1:8080/index.cgi | grep "Requests per
>> second"
>> Requests per second:    306.55 [#/sec] (mean)
>>
>> FCGI:
>> # ab -n100 -c10 http://127.0.0.1:8080/server.fcgi | grep "Requests  
>> per
>> second"
>> Requests per second:    952.44 [#/sec] (mean)
>>
>
> wow - not bad.  but could be better eh.
>
>
>> I think acgi could outperform fcgi, because the fcgi-protocol  
>> takes cares
>> about multiplexing and the ruby-fcgi is not multi-threaded. So this
>> multiplexing thing is maybe overhead. Do you plan a multithreaded
>> implementation of acgi on the ruby side? I guess not.
>>
>
> i've been playing with all sorts of things but am unclear as to  
> what the
> bottleneck is.  any suggestions welcome.
>
>
>> On the other hand the bottleneck is maybe the additional fork and  
>> exec, so
>> mod_acgi is maybe worth doing.
>>
>
> maybe.  just running
>
>   ./index.cgi </dev/null>/dev/null
>
> shows times between 0.001 and 0.01.  so it seems the low side is  
> about one
> hundred and the high around 1000 rps.  however, that it on my  
> machine where i
> only get about 80 and 160 rps for acgi and fcgi respectively.  i've  
> tried
> various things in the c program (pthreads, forking) to make it  
> faster and it
> makes little difference afaikt - so i think the speed must come on  
> the ruby
> side.  right now i'm thinking of a way operate in non-blocking mode
> exclusively but it'll take a little coding on the c side.  anyhow,  
> i'm out of
> town for a few days and will consider while i'm away.
>
> again, thanks for looking at this.
>
> cheers.
>
> -a
> -- 
> ====================================================================== 
> =========
> | email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> | phone :: 303.497.6469
> | Your life dwells amoung the causes of death
> | Like a lamp standing in a strong breeze.  --Nagarjuna
> ====================================================================== 
> =========
>
>
>