(no subject)

Tom Neff (tneff@ns1.bloomberg.com)
Wed, 19 Mar 1997 18:24:33 -0500

Message-Id: <3.0.32.19691231190000.01411a90@mothra.bloomberg.com>
Date: Wed, 19 Mar 1997 18:24:33 -0500
To: fastcgi-developers@OpenMarket.com
From: Tom Neff <tneff@ns1.bloomberg.com>
Subject: Re: 

At 12:47 PM 3/19/97 -0500, Stanley Gambarin wrote:
>Finally, it is very important to note that if your fastcgi applications take 
>a long time to execute (by long time I mean 10+ secs), the savings provided 
>by fastcgi in saving fork/exec calls become negligible compared to the time 
            =========================
>it takes to service the request and so you may resort to CGI for easy of
usage.

The key phrase here is "in saving fork/exec calls."  If the only reason you
went to FastCGI in the first place was to cut down process thrash, it may
not be worth it for very heavyweight operations.  BUT -- if you have a
repetitive process involving expensive and time-consuming setup, FastCGI
lets you do that part just once, even if the "once per hit" part is heavy.

To give you an example of what I mean:

	Open huuuuge/remote database - 20 seconds (real time)
	Build biiiig inverted tree from it - 12 seconds
	==> Process user key "SAMPLE KEY 123" - 10 seconds
	Close huuuuge/remote database and free resources - 3 seconds

Now if you do the above as a standalone CGI, you expend 45 seconds on
*every single hit*.  If you do it as a FastCGI (with only the "===>" step
inside the Accept loop) you spend 35 seconds *once* and just 10 seconds per
hit thereafter.  Fork/exec overhead is irrelevant here - you're still
saving a mountain of processor time.

I promise to shut up for a while now. :)
-- 
Tom Neff			Bloomberg, L.P.
<tneff@bloomberg.com>