Re: Re: Accept() loop in php-fcgi?

Dear Nikolay,

I have observed 5-10x performance gain on fastcgi-capable perl
scripts.  It's tricky to see where the performance gain actually came
from on php.  With heavy php scripts running within mod_php, is it
safe to say under high load, Apache has to fork many children to run
mod_php and the overhead of forking and back-logging on Apache is more
significant than doing them on stand-alone php processes over fastcgi?

30% or 40% would be a satisfactory mark, but so far my experiments
show php-fastcgi is about 10% slower than mod_php.

Thanks,

Jonathan

* Nikolay Ananiev <[email protected]> [2006-01-20 05:05]:
> There is no Accept loop in php, but there must be a performance gain. I
> don't know how you calculate it and I haven't done it personally,
> but what I read on the Zeus and lighttpd sites there seems to be %30 to %40
> gain in speed. Maybe the gain is outside the script so you
> can't measure it inside php.
> 
> "Jonathan Chen" <ccchen-z0t8KZiULAH2/[email protected]>
> wrote in message news:20060119211003.GA23946-z0t8KZiULAH2/9iHc7UuXHrh/kl/[email protected]
> Hi,
> 
> Recently I moved some of my php scripts from running on mod_php to
> (mod_fastcgi + php-fcgi) under Apache; hoping to see some gains on
> performance, however, I observed that having (mod_fastcgi + php-fcgi)
> brings almost no benefit.  On the other hand, the equivalent perl
> script runs 10x faster on (mod_fastcgi + perl).
> 
> On perl, I convert a script like:
> 
> #!/usr/bin/perl
> 
> use XXX; # heavy initialization stuff
> 
> print(“Content-type: text/html\n\n”); # start of response
> print(“Serving request...”);
> 
> to fastcgi script like:
> 
> #!/usr/bin/perl
> 
> use FCGI;
> use XXX; # heavy initialization stuff
> 
> while(FCGI::accept() >= 0) {
> print(“Content-type: text/html\n\n”); # start of response
> print(“Serving request...”);
> }
> 
> I am wondering if there is a notion of FCGI::accept() loop in php
> semantics?  It seems like php-fcgi implements the accept() outside of
> the php scripts, which makes me unable to seperate the heavy
> initialization part from the response part.
> 
> Any ideas?
> 
> Thanks,
> 
> Jonathan
> 
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> 
> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/
> 
> 
> 

> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/