The recommended way of installing Django sites is to use mod_python. mod_python allows Apache to serve content much more quickly than CGI, but using it can create problems that are difficult to debug.

mod_python embeds the python interpreter in Apache and can share python interpreters between virtual hosts. This means that a misbehaving Python program can do much more damage than it could if it was running as a CGI script.

For example: in an early version of excess.org I used md5.digest() to generate a key for caching with Django's cache module. It seemed to work, but then random pages started disappearing — when I requested them I would get an empty response and there was no log of the request in Apache.

It turns out that Django's caching is not 8-bit clean and there were some bytes being generated by md5.digest() that it didn't like. When this happened the whole interpreter died taking the Apache process with it. With no logging of the request let alone the error message, it was very hard to track down the problem.

Another problem is related to how mod_python shares processes between virtual hosts. When hosting multiple versions of the same site in different apache virtual hosts, such as a development version and a production version, Django can get confused and serve content from the wrong site. The solution proposed is to use the PythonInterpreter setting to force each site to use a different interpreter.

This setting can affect all the other virtual hosts in Apache as well. Once I added a PythonInterpreter setting to one virtual host I found that a Trac site I had stopped working. Apparently Trac expects to always be run from the same interpreter, so it too needed a PythonInterpreter setting.

I am uneasy about the way that mod_python creates opportunities for failures across virtual hosts and in the apache processes themselves. I plan to take a serious look at FastCGI as an alternative to mod_python.

Tags: Django