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