Server arrangements

NOTE: Much of this wiki document may be incorrect or out of date - the best current and maintained source of docs provided by Django can be found ​here

Because Django uses ​WSGI, it can run on any WSGI-compatible Web server. Here's how to run Django on various server arrangements.

Apache

Apache with mod_python

Apache with FastCGI

Apache with SCGI

  • ​SCGI can be used with Apache ​like this. It builds on stuff from the Apache+FCGI documentation above.

The material at simon.bofh.ms has been hard to get - server sometimes responds, sometimes not IME. In any event, #3047 has patches, and seems to be on track to become the official way to do SCGI with Django.

Apache with mod_wsgi

lighttpd

lighttpd with Apache

lighttpd with FastCGI

lighttpd with SCGI

FastCGI

Twisted.web2

nginx

I've been serving up my django site via nginx for a short while now and wanted to report my setup so that others may give it a shot. My performance over the previous setup with lighttpd is a bit better. This setup uses much less cpu and memory to achieve much better throughput and response time. The simple syntax of the nginx.conf allows you to setup a cluster of backend processes quite easily to handle load. Currently this is my nginx.conf relevant to my django site. You can reference the above links for more information about additional options. 

upstream djangoserv {
server 127.0.0.1:8801;
}

server {
listen 80;
root /path/to/app;
server_name test.local.domain;
access_log /path/to/logs/appname-access.log main;
error_log /path/to/logs/appname-error.log;

location /media  {
	alias /path/to/media;
}


location /styles  {
	alias /path/to/styles;
}

location /javascripts  {
	alias /path/to/javascripts;
}

location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) {
        access_log   off;
        expires      30d; 
}

location / {
                        # host and port to fastcgi server
                        fastcgi_pass 127.0.0.1:8801;
                        fastcgi_param PATH_INFO $fastcgi_script_name;
                        fastcgi_param REQUEST_METHOD $request_method;
                        fastcgi_param QUERY_STRING $query_string;
                        fastcgi_param SERVER_NAME $server_name;
                        fastcgi_param SERVER_PORT $server_port;
                        fastcgi_param SERVER_PROTOCOL $server_protocol;
                        fastcgi_param CONTENT_TYPE $content_type;
                        fastcgi_param CONTENT_LENGTH $content_length;
                        fastcgi_pass_header Authorization;
                        fastcgi_intercept_errors off;
}
}

Once you fire up nginx you will need to start your nginx fastcgi processes. I simply use: 

python2.4 manage.py runfcgi method=threaded host=127.0.0.1 port=8801

Django behind/inside Zope

It's possible to query a Django site from Zope or Plone and return the result. This allows you to include a Django site inside a pre-existing Zope/Plone site. It's good for custom content that you don't want to use existing Zope technologies to develop. The main trick is to write a "Script (Python)" object that loads up Django's request handling mechanisms, while ensuring (as with any Django deployment) that your Django site is on the current PYTHONPATH and that the env var DJANGO_SETTINGS_MODULE is set to your project's settings file. I'm afraid I've lost the original code that did this but the approach was pretty simple.

However, an even better approach showed up later (found due to Plone's caching mechanisms causing problems with the above -- it would occasionally call the script multiple times, which on POSTs is a very bad thing...) which is simply to use Apache as the primary frontend, and using mod_proxy to send some requests to the Plone app server running on another port, with other requests going to your Django site, however you wish to deploy it with Apache (I used mod_python, would be using mod_wsgi today). E.g. proxy /cms and /documents to Plone, with a catchall serving up your Django site. (Or vice-versa, if you desire -- it's all just Apache at this point.)

With this latter approach, I also had to create a simple Plone script, but this one was for the Django site to query Plone to ask about credentials, since I was using Plone for authentication. I.e. a simple Django middleware would look for the Plone auth cookie and send it onwards to the Plone script, which would use the username or token to check whether the credentials were accurate / the user had a currently live session. It would then return a boolean value and anything else the Django code needed to know (e.g. list of group memberships).

As with the even older code, this code is no longer around :(

CGI

Running Django as a traditional CGI is possible and would work the same as running any other sort of Python CGI script, but is generally not recommended.

With traditional CGI, the program which will be run -- in this case, Django plus a Django-powered application -- is loaded from disk into memory each time a request is served, which results in a significant amount of processing overhead and much slower responses. FastCGI and SCGI, in contrast, load the code only once -- when the server starts up -- and keep it in memory as long as the server is running, resulting in much faster responses.

If that hasn't put you off and you still need CGI, take a look at #2407.

CherryPy and WSGI

Devserver - Django built-in development server

Differences between Devserver and production

Cherokee

Cherokee with FastCGI

Cherokee with SCGI

Cherokee with uWSGI

Last modified 12 years ago Last modified on Nov 9, 2012, 11:07:45 AM
Note: See TracWiki for help on using the wiki.
Back to Top