Re: Benchmark for fastcgi

Apache was never designed to be a high performance server.  Comparing
plugins like this are fairly meaningless tbh.  They favour the
solutions which empirically are hard to program in and lead to segfault
after segfault after segfault like mod_perl or poorly designed
abberations like PHP.

It's been known for a long time that throwing away memory protection by
compiling everything together as one process leads to performance
enhancements at the cost of, well, memory protection.  IPC just gets
faster and faster as time goes on, but segfaults are there to stay.

If you want meaningful benchmarks out of what's possible with FastCGI,
consider testing the performance in concert with a pure user threading
web server, such as Zeus, LiteSpeed, thttpd-pro, lighttpd, etc.

As just about all mod_perl sites "graduate" to a situation where all
their applications run with their own apache thunderstorm of processes,
To compare apples with apples you'd want to compare:

   +-----------+     TCP    +-----------+
   |  Apache   |  <======>  |  Apache   |
   | mod_proxy |            | mod_hello |
   +-----------+            +-----------+

   (the front-end proxy here isn't important, you could instead use
    a high performance option like LiteSpeed)

with something like this:

   +-----------+     TCP    +---------+
   | lighttpd  |  <======>  | FCGI    |
   | fastcgi   |            | hello.c |
   +-----------+            +---------+

That will give you a more true representation of the real performance
benefits of using FastCGI.

And that's before you start taking into consideration things like
memory footprints.

Sam.


Per Andersson wrote:
> Do any of you have any data on benchmarking of fastcgi. What I am primerily 
> interested in is sending 5k html data embedded in C printf statements in a C 
> fcgi application. From what I have read fastcgi could even be faster than direct 
> seb server API. Is this true? From the benchmark below it does not seem true.
> 
> I have seen this benchmark,
> 
> http://chamas.com/bench/
> 
> There it states [Apache server],
> 
> 28 k output:
> C Apache API mod_h2000      2008.7 hits/sec
> mod_php PHP 2000            651.7  hits/sec
> [No data available for fastcgi]
> 
> 214 byte output:
> C Apache API                 4285.2 hits/sec
> mod_php PHP                  1601.2 hits/sec
> mod_fastcgi                  911.9 hits/sec
> 
> As you can see php is actually faster! What I wonder from these results is if 
> how the fastcgi app was done, was it a perl interpreted page or was it a C 
> application?
> 
> What do you think of these results?
> 
> Regards,
> 
> /Per
> 
> -------------------------------------------------
> FREE E-MAIL IN 1 MINUTE!
>  - your.name-yckex/[email protected] - http://www.pc.nu
> 
> 
> ------------------------------------------------------------------------
> 
> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/

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