I was curious about what it would take to add forking/multi-process support to ajp-wsgi and apparently the answer is:
not much!
Well, it becomes trivial when you don't bother with preforking or process pools. I don't think an AJP backend really needs to worry much about saving fork() time since connections (and therefore processes) are more or less persistant.
I've done some basic stress testing using ApacheBench (ab): 100 concurrent requests, 500 concurrent requests. It's looking promising (no errors!). I haven't done any extensive testing between threaded vs. forking, but the results seem to be the same (using a freshly created Pylons app). Obviously the GIL isn't really being exercised when serving a static ~5K page.
And I did learn one oddity about mod_proxy/mod_proxy_ajp — apparently, when you specify max connections, you're actually specifying max connections
per httpd process. On my server, where httpd uses the worker MPM (hybrid thread/process), the hard process limit is apparently 16, so even specifying max=1 means ajp-wsgi can expect up to 16 connections. (Conveniently for me, ajp-wsgi's default
process limit is 16.) Something to keep in mind when tweaking ajp-wsgi's maxConnections parameter.
(Also note that if mod_proxy_ajp ever goes over ajp-wsgi's maxConnections limit, users
will see HTTP 503 errors.)
Anyway, I think I'll stick to threading for now. But 1.1 alpha is out there for anyone interested...
ChangeLog
Tarball
Hg repository
