modwsgi. Apache module (written in C) for hosting Python WSGI applications, no mod_python required. Includes Django integration instructions. Has anyone tried this out?
Sign in with 
OpenID
modwsgi. Apache module (written in C) for hosting Python WSGI applications, no mod_python required. Includes Django integration instructions. Has anyone tried this out?
Yes, I have it running. Seems to work just fine for Trac and some WSGI test thingies I have. Haven't tried any stress tests.
It is MUCH nicer than mod_python if you're doing WSGI, though.
I've given it a shot (with Django, natch).
Unscientifically it appears roughly a bit faster (10%, maybe?) with about the same memory overhead. Stability is of course something that's hard to test for, and it's gonna be hard to beat the rock-solidness of mod_python. Still, I'm keeping a close eye on modwsgi; it could become a great way to deploy Python sites with a minimum of fuss.
Id like to know if it meets the holy grail of apache processes, that it can run with the threading MPM. my muddy recollection is that any usage of python sub-interpreters renders threads as unstable and modwsgi is still using sub-interpreters.
mike bayer - 14th April 2007 17:39 - #
I'll stick with scgi -- I hate the idea of having python bloating up all my apache handlers (especially since it's not thread MPM friendly?)
dbt - 14th April 2007 22:14 - #
Hmmm, mod_wsgi is not even officially released yet and already the same myths and misconceptions that people propagate about mod_python are being applied to it.
First off, mod_wsgi (as does mod_python) works fine with threaded Apache MPMs such as worker on UNIX and the Windows winnt MPM. Any problems people have seen with mod_python specifically are because they are using quite old versions of mod_python which did have some multi threading bugs in them, are using web applications on top of Apache that are not thread safe or are using third party C extension modules that aren't written properly to work with multiple sub interpreters. Thus, mod_wsgi itself has no problems with multi threading, it is the stuff that gets used on top of it.
As far as claims that mod_wsgi will bloat out the size of Apache child processes, this is not strictly true. The first problem with bloating when using Python embedded within Apache is that the version of Python being used was not built with the --enable-shared option. This means that the Python library itself ends up being embedded within each Apache child process rather than one instance being shared across the whole system. The second problem with bloating is that the main Python web frameworks are very fat. For a basic application Django adds 5MB of Python code with TurboGears adding up to 15MB of Python code to every Apache child process. Thus, mod_wsgi doesn't itself cause the code bloat and for a simple hello world application only adds a few hundred kilobytes.
FWIW, a feature is being added to mod_wsgi that will allow WSGI applications to be hosted in a separate daemon process so that bloat caused by these fat applications doesn't affect the main Apache child processes. Because the whole thing is tailored to WSGI, it is much simpler to setup and configure as you only need mod_wsgi and don't need a separate SCGI/FASTCGI supporting framework.
If you are going to speculate, why not come over to the Google mod_wsgi group and find out what the truth is first. :-(
Graham Dumpleton - 15th April 2007 01:25 - #