Re: Performance data?

Andrew Kuchling (
Fri, 23 Aug 1996 21:47:31 -0400 (EDT)

From: Andrew Kuchling <>
Message-Id: <>
Subject: Re: Performance data?
Date: Fri, 23 Aug 1996 21:47:31 -0400 (EDT)
In-Reply-To: <> 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 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

> 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

	Andrew Kuchling