Apache with mod_python currently is the most robust setup for using Django on a production server. mod_python (http:\/\/www.djangoproject.com\/r\/mod_python\/) is an Apache plug-in that embeds Python within Apache and loads Python code into memory when the server starts. Code stays in memory throughout the life of an Apache process, which leads to significant performance gains over other server arrangements. Django requires Apache 2.x and mod_python 3.x, and we prefer Apache\u2019s prefork MPM, as opposed to the worker MPM.<\/p>\n
Note<\/strong> – Configuring Apache is well<\/em> beyond the scope of this book, so we\u2019ll simply mention details as needed. Luckily, a number of great resources are available if you need to learn more about Apache. A few of them we like are as follows:<\/p>\n Basic Configuration<\/u> – To configure Django with mod_python, first make sure you have Apache installed with the mod_python module activated. This usually means having a LoadModule directive in your Apache configuration file. It will look something like this:<\/p>\n LoadModule python_module \/usr\/lib\/apache2\/modules\/mod_python.so<\/p>\n Then, edit your Apache configuration file and add the following:<\/p>\n <Location “\/”> Make sure to replace mysite.settings with the appropriate DJANGO_SETTINGS_MODULE for your site. This tells Apache, \u201cUse mod_python for any URL at or under \u2018\/\u2019, using the Django mod_python handler.\u201d It passes the value of DJANGO_SETTINGS_MODULE so mod_python knows which settings to use. Note that we\u2019re using the <Location> directive, not the <Directory> directive. The latter is used for pointing at places on your filesystem, whereas <Location> points at places in the URL structure of a Web site. <Directory> would be meaningless here.<\/p>\n Apache likely runs as a different user than your normal login and may have a different path and sys.path. You may need to tell mod_python how to find your project and Django itself.<\/p>\n PythonPath “[‘\/path\/to\/project’, ‘\/path\/to\/django’] + sys.path”<\/p>\n You can also add directives such as PythonAutoReload Off for performance. Note that you should set PythonDebug Off on a production server. If you leave PythonDebug On, your users will see ugly (and revealing) Python tracebacks if something goes wrong within mod_python. Restart Apache, and any request to your site (or virtual host if you\u2019ve put this directive inside a <VirtualHost> block) will be served by Django.<\/p>\n Note – If you deploy Django at a subdirectory<\/strong> \u2014 that is, somewhere deeper than \u201c\/\u201d \u2014 Django won\u2019t trim the URL prefix off of your URLpatterns. So if your Apache config looks like this:<\/p>\n <Location “\/mysite\/”> then all your URL patterns will need to start with “\/mysite\/”. For this reason we usually recommend deploying Django at the root of your domain or virtual host. Alternatively, you can simply shift your URL configuration down one level by using a shim URLconf:<\/p>\n urlpatterns = patterns(”, Running Multiple Django Installations on the Same Apache Instance<\/strong> – It\u2019s entirely possible to run multiple Django installations on the same Apache instance. You might want to do this if you\u2019re an independent Web developer with multiple clients but only a single server. To accomplish this, just use VirtualHost like so:<\/p>\n NameVirtualHost * <VirtualHost *> If you need to put two Django installations within the same VirtualHost, you\u2019ll need to take a special precaution to ensure mod_python\u2019s code cache doesn\u2019t mess things up. Use the PythonInterpreter directive to give different <Location> directives separate interpreters:<\/p>\n <VirtualHost *> <Location “\/otherthing”> The values of PythonInterpreter don\u2019t really matter, as long as they\u2019re different between the two Location blocks.<\/p>\n Running a Development Server with mod_python<\/strong> – Because mod_python caches loaded Python code, when deploying Django sites on mod_python you\u2019ll need to restart Apache each time you make changes to your code. This can be a hassle, so here\u2019s a quick trick to avoid it: just add MaxRequestsPerChild 1 to your config file to force Apache to reload everything for each request. But don\u2019t do that on a production server, or we\u2019ll revoke your Django privileges.<\/p>\n If you\u2019re the type of programmer who debugs using scattered print statements (we are), note that print statements have no effect in mod_python; they don\u2019t appear in the Apache log, as you might expect. If you have the need to print debugging information in a mod_python setup, you\u2019ll probably want to use Python\u2019s standard logging package. More information is available at http:\/\/docs.python.org\/lib\/module-logging.html. Alternatively, you can or add the debugging information to the template of your page.<\/p>\n Serving Django and Media Files from the Same Apache Instance<\/strong> – Django should not be used to serve media files itself; leave that job to whichever Web server you choose. We recommend using a separate Web server (i.e., one that\u2019s not also running Django) for serving media. If, however, you have no option but to serve media files on the same Apache VirtualHost as Django, here\u2019s how you can turn off mod_python for a particular part of the site:<\/p>\n <Location “\/media\/”> Change Location to the root URL of your media files. You can also use <LocationMatch> to match a regular expression. For example, this sets up Django at the site root but explicitly disables Django for the media subdirectory and any URL that ends with .jpg, .gif, or .png:<\/p>\n <Location “\/”> <Location “\/media\/”> <LocationMatch “\\.(jpg|gif|png)$”> In all of these cases, you\u2019ll need to set the DocumentRoot directive so Apache knows where to find your static files.<\/p>\n Error Handling<\/strong> – When you use Apache\/mod_python, errors will be caught by Django \u2014 in other words, they won\u2019t propagate to the Apache level and won\u2019t appear in the Apache error_log. Handling a Segmentation Fault<\/strong> – Sometimes, Apache segfaults when you install Django. When this happens, it\u2019s almost always one of two causes mostly unrelated to Django itself:<\/p>\n \uf0fc It may be that your Python code is importing the pyexpat module (used for XML parsing), which may conflict with the version embedded in Apache.. If you continue to have problems setting up mod_python, a good thing to do is get a bare-bones mod_python site working, without the Django framework. This is an easy way to isolate mod_python-specific problems. The article \u201cGetting mod_python Working\u201d details this procedure: http:\/\/www.djangoproject.com\/r\/articles\/getting-modpython-working\/.<\/p>\n The next step should be to edit your test code and add an import of any Django-specific code you\u2019re using \u2014 your views, your models, your URLconf, your RSS configuration, and so forth. Put these imports in your test handler function and access your test URL in a browser. If this causes a crash, you\u2019ve confirmed it\u2019s the importing of Django code that causes the problem. Gradually reduce the set of imports until it stops crashing, so as to find the specific module that causes the problem. Drop down further into modules and look into their imports as necessary. For more help, system tools like ldconfig on Linux, otool on Mac OS, and ListDLLs (from SysInternals) on Windows can help you identify shared dependencies and possible version conflicts.<\/p>\n\n\n\n
\nSetHandler python-program
\nPythonHandler django.core.handlers.modpython
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\nPythonDebug On
\n<\/Location><\/p>\n
\nSetHandler python-program
\nPythonHandler django.core.handlers.modpython
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\nPythonDebug On
\n<\/Location><\/p>\n
\n(r’^mysite\/’, include(‘normal.root.urls’)),
\n)<\/p>\n
\n<VirtualHost *>
\nServerName www.example.com
\n# …
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\n<\/VirtualHost><\/p>\n
\nServerName www2.example.com
\n# …
\nSetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
\n<\/VirtualHost><\/p>\n
\nServerName www.example.com
\n# …
\n<Location “\/something”>
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\nPythonInterpreter mysite
\n<\/Location><\/p>\n
\nSetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
\nPythonInterpreter mysite_other
\n<\/Location>
\n<\/VirtualHost><\/p>\n
\nSetHandler None
\n<\/Location><\/p>\n
\nSetHandler python-program
\nPythonHandler django.core.handlers.modpython
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\n<\/Location><\/p>\n
\nSetHandler None
\n<\/Location><\/p>\n
\nSetHandler None
\n<\/LocationMatch><\/p>\n
\nThe exception to this is if something is really messed up in your Django setup. In that case, you\u2019ll see an \u201cInternal Server Error\u201d page in your browser and the full Python traceback in your Apache error_log file. The error_log traceback is spread over multiple lines. (Yes, this is ugly and rather hard to read, but it\u2019s how mod_python does things.)<\/p>\n
\n\uf0fc It may be because you\u2019re running mod_python and mod_php in the same Apache instance, with MySQL as your database back-end. In some cases, this causes a known mod_python issue due to version conflicts in PHP and the Python MySQL back-end.<\/p>\n