Re: Performance data?

Andrew Kuchling (amk@magnet.com)
Fri, 23 Aug 1996 21:47:31 -0400 (EDT)

From: Andrew Kuchling <amk@magnet.com>
Message-Id: <199608240147.VAA15974@lemur.magnet.com>
Subject: Re: Performance data?
To: fastcgi-developers@openmarket.com
Date: Fri, 23 Aug 1996 21:47:31 -0400 (EDT)
In-Reply-To: <199608240024.UAA09536@dolphin.automatrix.com> from "Skip Montanaro" at Aug 23, 96 08:24:23 pm

Skip Montanaro wrote:
> Andy's code was written entirely in Python, but I still thought it wouldn't
> do too badly against the fork/exec overhead of CGI.  There isn't that much
	
	fastcgi.py implements things in the dumbest, brute-force way,
using lots and lots of redundant string operations.  I'm sure
optimization would be possible, but I now think it would be a better
approach to write a Python module that used the fcgiapp library; it
would be faster at the string-cracking stuff, and would keep up with
changes to the protocol more easily, as long as the C library gets
updated.

> was performed.  Both of the scripts did virtually no real work, just spit
> out a Content-type: header and a time.  Both were written in Python.

	That's another thing; my code wouldn't help with that case,
and, as you point out, actually hurts.  John Mitchell (also of Magnet)
ran a test with a FastCGI script that connected to an Illustra
database and ran a SELECT statement.  The connection takes about a
second or two to set up, but only has to be done once by a FastCGI
process, while every CGI process incurs that delay.  Here the savings
were sizable; the FastCGI version was, I think, about 4 times faster
on average because it didn't have to create a connection.  For a no-op
script, you're saving the cost of a fork()+exec(), but I'll wager the
gain is entirely lost by the slow Python code implementing the FastCGI
protocol.


	Andrew Kuchling
	amk@magnet.com