Ian Bicking: the old part of his blog

Re: Towards php comment 000


You would be better served to consider SCGI. Go to http://www.fastcgi.com/dist/ and check out the last-modified dates. The most recent stable release was Jan 19, 2003. The most recent SNAPSHOT is April 14, 2004. Contrast this with SCGI ( last release Feb 2, 2006 ) http://www.mems-exchange.org/software/scgi/scgi-1.10.tar.gz/scgi-1.10/CHANGES SCGI is vibrant and python-centric. mod_scgi is robust and stable for Apache 1.3x and 2.0x scgi_server.py is small, well-written, and easily extensible.

re: threads You are absolutely right

re: per-user processes This is problematic. You will need a master-process with root-privileges to fork/setuid all these lower-privileged process. This is a big security hole unless you do it exactly right ( Note the apparent deadend of the apache2 perchild mpm. ) This program will be talking to the internet. Running as root is hubris. It would be better to serve all requests for all hosts as one unprivileged user.

re: PHP I loathe PHP, but I believe that one of PHP's greatest virtues is as follows: Consider an apache server with 200 virtual-hosts. Each virtual host has 100 php-scripts. The run-time cost of these 20,000 php-scripts is only that whatever pages the server is currently serving. If the request rate is 1 page/second or less the load-average is 0-0-0. It doesn't matter whether there are 100 virtual-hosts or 1. It doesn't matter whether there are 20,000 distinct php-scripts available or 1.

A tomcat installation with 20,000 distinct .jsp pages by comparison would be in swap-storm standing still.

Most python web-application frameworks tend to favor the tomcat model. They work great for complex apps on a dedicated machine.

Providing simple and robust dynamic web-pages for scores of unrelated virtual-hosts with low resource utilization, not so much.

Comment on Towards php comment 000
by Christopher Mulcahy