From: "Ara.T.Howard" Date: 2005-09-20T05:17:28+09:00 Subject: Re: acgi-0.1.0 On Mon, 19 Sep 2005, Dan Janowski wrote: > My applause to you on trying to replace FastCGI. I gave up on it after > inexplicable weirdness began to set in. i know the feelings. it can be setup well - but it's non-trivial. > 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). this is what i'm hoping. also i strongly feel that writing an apache module would be the path to ruin. > 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. yeah... but an mmap protocol would not block when the the 'pipe was full' and would require a custom com protocol. i am considering it though. i haven't given up on other alternative yet thought - not least of which a c cgi extension - perhaps a wrapper on cgic. btw. i you are interested in playing around with the code let me know - i could use some help ;-) cheers. > > 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: >>> >>> >>> StartServers 100 >>> MinSpareServers 100 >>> MaxSpareServers 100 >>> MaxClients 250 >>> MaxRequestsPerChild 50 >>> >>> >> >> 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 >> >> 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 >> ====================================================================== >> ========= >> >> >> > > -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 ===============================================================================