Ian Bicking: the old part of his blog

The concurrency model debate comment 000

Personally it's the Apache side of FastCGI that has always been hard for me to set up, not the Python side. Other people are also using HTTP proxying, which is better supported still, but unfortunately doesn't have quite the same information as FastCGI passes through (SCRIPT_NAME and PATH_INFO particularly, but other information like REMOTE_USER is also lost -- resolveable through configuration, but then it's no longer as easy to configure).
Comment on Re: The Concurrency Model Debate
by Ian Bicking

Comments:

Apache 2.1 will finally add the ability to load-balance mod_proxy requests, and I trust HTTP more than a semi-orphaned protocol like FastCGI or its clones.

Until recently we were running mod_proxy on a farm of Apache 1.3 servers to funnel about 300,000 HTTP requests per day into a single multithreaded Python BaseHTTPServer process (using the PSP engine from WebWare, with the rest of WebWare ripped out), on a lowly P3/500, no less. GIL contention is probably less of an issue than many people believe in real-world applications, although it would help if there were a tool to measure it and/or something like an exponentially decaying average of the numbers of threads waiting to acquire the GIL.

# Fazal Majid

And, just in case you didn't know, there is now a way to write WSGI capable applications that use FastCGI and any capable web server (apache and lighttpd). I wrote a quick howto for setting up lighttpd to use it on my weblog:

http://www.cleverdevil.org/computing/24/python-fastcgi-wsgi-and-lighttpd

# Jonathan LaCour