Allan Saddi's projects blog

I haven't run into any problems with scgi-wsgi in the few weeks that I've been using it. My issues with SCGI stem from mod_scgi and mod_proxy_scgi.

Namely, I think mod_scgi's handling of environment variables is perfect (see my previous rants about mod_proxy_scgi). It's even slightly faster than mod_proxy_scgi. But configuration leaves a bit to be desired. Say I want to mount an application at the root but I want the path "/static" to be handled by the web server. How does one do this? I'm guessing it has something to do with the SCGIHandler on/off directive (in fact, it probably is that simple) — but that method is a bit way too verbose, especially if you have multiple exclusions.

I like the way the mod_proxy_* stuff is configured (namely with ProxyPass). It's easy to exclude directories. And the directives are parsed in order, meaning configuration is sane and intuitive (at least to me). You specify the most specific entries first.

But again, see my rant about mod_proxy_scgi's environment handling.

Anyway, scgi-wsgi incorporates both a thread pool and a process pool. Since handling is done on a per-request basis, I thought it would be poor form if scgi-wsgi simply closed the connection from the web server if the pool was full — so instead, requests received are queued when the pool is over capacity. (This is in contrast to ajp-wsgi which does drop connections, but again, there's no 1:1 mapping between AJP connections and requests.) So you can have your app running on a single thread/process and still dozens or hundreds of concurrent requests. Those requests won't be served in a timely manner, but at least they will be served.

On my server, scgi-wsgi is one of the fastest WSGI servers I've tried (that's out of flup, ajp-wsgi, Paste's scgiserver, and CherryPy's web server). I have no idea what the state of the art in the WSGI world is, but it was certainly impressive enough to get me to write the thread/process pool code and start switching over my applications. And unlike CherryPy, it had the disadvantage (like the others) of sitting behind Apache httpd. (Though the fact that CherryPy is quite fast and speaks HTTP natively will probably stave off any urge to glue together an embeddable C web server and my C WSGI code... for a while. )

So anyway: scgi-wsgi. I've put it in its own space for now. Additional, more interesting links below.

ChangeLog
Tarball
Hg Repository

Well, it's been a few weeks since I've touched (or had the need to touch) ajp-wsgi. I've been running it a few places — sometimes forked if the app allowed it.

Anyway, the biggest new feature is, of course, forking support. I think now is a good time to "release" it, as any.

The 1.1 release will probably be the last for ajp-wsgi (barring any bugfix releases). I imagine I'll be folding AJP support into scgi-wsgi in the future (and renaming it all too). At this point, scgi-wsgi is a bit more advanced than ajp-wsgi with its thread pooling and pre-fork multiprocessing. Though neither of those features are really required (or make sense) with AJP's persistent connections.

scgi-wsgi 1.1 will follow in a few days.

ChangeLog
Tarball
Hg Repository