Re: Performance Gain?

Mark Brown (mbrown@openmarket.com)
Fri, 13 Sep 1996 09:42:15 -0400

Message-Id: <199609131342.JAA15351@breckenridge.openmarket.com>
To: fastcgi-developers@openmarket.com
Subject: Re: Performance Gain? 
In-Reply-To: <323875DB.1CFB@nineco.com> 
Date: Fri, 13 Sep 1996 09:42:15 -0400
From: Mark Brown <mbrown@openmarket.com>


Michael Colena says:

    So by switching from CGI to FastCGI I was expecting to see a gain
    due to process persistence. Instead I'm seeing not much of a
    difference.

Would you please explain what you observed: What was the application,
how did you configure it, how did you generate load, what did you measure
(e.g. latency, throughput, system utilization) and how, was the measurement
at the server only or end-to-end, if end-to-end what is the network like,
what is the server platform, etc.

Depending upon the test conditions you can make a FastCGI application
run much slower than CGI or much faster than CGI.

    Is the fork/exec of a CGI process really not that expensive enough
    to be sole performance gain? Is the only way to better performance
    thru session affinity?  How & where does FastCGI pay off?

There's a paper on this topic:

    http://www.fastcgi.com/kit/doc/fcgi-perf.htm

The paper focuses on FastCGI versus Web server APIs, but the same
principles apply to FastCGI versus CGI.

The short answer to the fork/exec question is: fork/exec is slow but
for a small binary not *that* slow.  What generally kills CGI performance
is large binaries and programs that require elaborate initialization:
reading config files, opening database connections, etc.

    --mark