At 12:00 AM 4/1/05 -0800, Shannon -jj Behrens wrote:
> In theory FastCGI is the way to do all of this, but despite my
> best efforts I can never get it to work.  Well "best efforts" might
> indicate more work than I've actually put into it, but enough effort to
> leave me thoroughly annoyed ;)

Perhaps off topic, I added FastCGI support to Aquarium in the last
release.  If you'd like, you can steal the code.  Here are the docs:

<http://aquarium.sourceforge.net/api/public/aquarium.wsadaptor.FastCGIAdaptor.FastCGIAdaptor-class.html>

Perhaps even further off topic, I'll second Ian's comment that getting FastCGI set up is a royal pain, especially if you are having Apache start the processes. mod_fastcgi has quite a few poorly documented and half-broken options that interact with each other in bizarre ways. The situation is somewhat better if you start the processes yourself, as then you only have to deal with a handful of poorly-documented timeout/retry parameters. :) PEAK's "FastCGI supervisor" tool manages forking pre-initialized processes (and killing them off) according to a set of simpler, saner options. I wrote it while at Verio so that we could increase performance relative to having Apache start the processes, and getting rid of the configuration headaches was a big plus.


Anyway, PEAK's FastCGI supervisor can run any WSGI application, so if you have a high-load application that needs multiple processes to take full advantage of your server hardware, but you don't want to have as many processes as mod_python would create, you should take a look at it.

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Reply via email to