Although WSGI is the preferred deployment\nplatform for Django, many people use shared hosting, on which protocols such as\nFastCGI, SCGI or AJP are the only viable options.
\n\nEssentially, FastCGI is an efficient way of letting an external application\nserve pages to a Web server. The Web server delegates the incoming Web requests\n(via a socket) to FastCGI, which executes the code and passes the response back\nto the Web server, which, in turn, passes it back to the client’s Web browser.
\nLike WSGI, FastCGI allows code to stay in memory, allowing requests to be\nserved with no startup time. While\ne.g. mod_wsgi can either be configured\nembedded in the Apache Web server process or as a separate daemon process, a\nFastCGI process never runs inside the Web server process, always in a separate,\npersistent process.
\n\nBefore you can start using FastCGI with Django, you’ll need to install flup, a\nPython library for dealing with FastCGI. Version 0.5 or newer should work fine.
\nFastCGI operates on a client-server model, and in most cases you’ll be starting\nthe FastCGI process on your own. Your Web server (be it Apache, lighttpd, or\notherwise) only contacts your Django-FastCGI process when the server needs a\ndynamic page to be loaded. Because the daemon is already running with the code\nin memory, it’s able to serve the response very quickly.
\n\nA Web server can connect to a FastCGI server in one of two ways: It can use\neither a Unix domain socket (a “named pipe” on Win32 systems), or it can use a\nTCP socket. What you choose is a manner of preference; a TCP socket is usually\neasier due to permissions issues.
\nTo start your server, first change into the directory of your project (wherever\nyour manage.py is), and then run the\nrunfcgi command:
./manage.py runfcgi [options]\nIf you specify help as the only option after runfcgi, it’ll\ndisplay a list of all the available options.
You’ll need to specify either a socket, a protocol\nor both host and port. Then, when you set up your\nWeb server, you’ll just need to point it at the host/port or socket you\nspecified when starting the FastCGI server. See the examples, below.
Django supports all the protocols that flup does, namely fastcgi, SCGI and\nAJP1.3 (the Apache JServ Protocol, version 1.3). Select your preferred\nprotocol by using the protocol option\nwith ./manage.py runfcgi – where <protocol_name> may be one of:\nfcgi (the default), scgi or ajp. For example:
./manage.py runfcgi protocol=scgi\nRunning a threaded server on a TCP port:
\n./manage.py runfcgi method=threaded host=127.0.0.1 port=3033\nRunning a preforked server on a Unix domain socket:
\n./manage.py runfcgi method=prefork socket=/home/user/mysite.sock pidfile=django.pid\nRun without daemonizing (backgrounding) the process (good for debugging):
\n./manage.py runfcgi daemonize=false socket=/tmp/mysite.sock maxrequests=1\nIf you have the process running in the foreground, it’s easy enough to stop it:\nSimply hitting Ctrl-C will stop and quit the FastCGI server. However, when\nyou’re dealing with background processes, you’ll need to resort to the Unix\nkill command.
If you specify the pidfile option to runfcgi, you can\nkill the running FastCGI daemon like this:
kill `cat $PIDFILE`\n…where $PIDFILE is the pidfile you specified.
To easily restart your FastCGI daemon on Unix, try this small shell script:
\n#!/bin/bash\n\n# Replace these three settings.\nPROJDIR="/home/user/myproject"\nPIDFILE="$PROJDIR/mysite.pid"\nSOCKET="$PROJDIR/mysite.sock"\n\ncd $PROJDIR\nif [ -f $PIDFILE ]; then\n kill `cat -- $PIDFILE`\n rm -f -- $PIDFILE\nfi\n\nexec /usr/bin/env - \\\n PYTHONPATH="../python:.." \\\n ./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE\nTo use Django with Apache and FastCGI, you’ll need Apache installed and\nconfigured, with mod_fastcgi installed and enabled. Consult the Apache\ndocumentation for instructions.
\nOnce you’ve got that set up, point Apache at your Django FastCGI instance by\nediting the httpd.conf (Apache configuration) file. You’ll need to do two\nthings:
Use the FastCGIExternalServer directive to specify the location of\nyour FastCGI server.
Use mod_rewrite to point URLs at FastCGI as appropriate.
The FastCGIExternalServer directive tells Apache how to find your FastCGI\nserver. As the FastCGIExternalServer docs explain, you can specify either a\nsocket or a host. Here are examples of both:
# Connect to FastCGI via a socket / named pipe.\nFastCGIExternalServer /home/user/public_html/mysite.fcgi -socket /home/user/mysite.sock\n\n# Connect to FastCGI via a TCP host/port.\nFastCGIExternalServer /home/user/public_html/mysite.fcgi -host 127.0.0.1:3033\nIn either case, the file /home/user/public_html/mysite.fcgi doesn’t\nactually have to exist. It’s just a URL used by the Web server internally – a\nhook for signifying which requests at a URL should be handled by FastCGI. (More\non this in the next section.)
The second step is telling Apache to use FastCGI for URLs that match a certain\npattern. To do this, use the mod_rewrite module and rewrite URLs to\nmysite.fcgi (or whatever you specified in the FastCGIExternalServer\ndirective, as explained in the previous section).
In this example, we tell Apache to use FastCGI to handle any request that\ndoesn’t represent a file on the filesystem and doesn’t start with /media/.\nThis is probably the most common case, if you’re using Django’s admin site:
<VirtualHost 12.34.56.78>\n ServerName example.com\n DocumentRoot /home/user/public_html\n Alias /media /home/user/python/django/contrib/admin/media\n RewriteEngine On\n RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]\n RewriteCond %{REQUEST_FILENAME} !-f\n RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L]\n</VirtualHost>\nDjango will automatically use the pre-rewrite version of the URL when\nconstructing URLs with the {% url %} template tag (and similar\nmethods).
Another way to serve applications through FastCGI is by using Apache’s\nmod_fcgid module. Compared to mod_fastcgi mod_fcgid handles FastCGI\napplications differently in that it manages the spawning of worker processes\nby itself and doesn’t offer something like FastCGIExternalServer. This\nmeans that the configuration looks slightly different.
In effect, you have to go the way of adding a script handler similar to what\nis described later on regarding running Django in a shared-hosting\nenvironment. For further details please refer to the\nmod_fcgid reference
\nlighttpd is a lightweight Web server commonly used for serving static files. It\nsupports FastCGI natively and, thus, is a good choice for serving both static\nand dynamic pages, if your site doesn’t have any Apache-specific needs.
\nMake sure mod_fastcgi is in your modules list, somewhere after\nmod_rewrite and mod_access, but not after mod_accesslog. You’ll\nprobably want mod_alias as well, for serving admin media.
Add the following to your lighttpd config file:
\nserver.document-root = "/home/user/public_html"\nfastcgi.server = (\n "/mysite.fcgi" => (\n "main" => (\n # Use host / port instead of socket for TCP fastcgi\n # "host" => "127.0.0.1",\n # "port" => 3033,\n "socket" => "/home/user/mysite.sock",\n "check-local" => "disable",\n )\n ),\n)\nalias.url = (\n "/media" => "/home/user/django/contrib/admin/media/",\n)\n\nurl.rewrite-once = (\n "^(/media.*)$" => "$1",\n "^/favicon\\.ico$" => "/media/favicon.ico",\n "^(/.*)$" => "/mysite.fcgi$1",\n)\nlighttpd lets you use “conditional configuration” to allow configuration to be\ncustomized per host. To specify multiple FastCGI sites, just add a conditional\nblock around your FastCGI config for each site:
\n# If the hostname is 'www.example1.com'...\n$HTTP["host"] == "www.example1.com" {\n server.document-root = "/foo/site1"\n fastcgi.server = (\n ...\n )\n ...\n}\n\n# If the hostname is 'www.example2.com'...\n$HTTP["host"] == "www.example2.com" {\n server.document-root = "/foo/site2"\n fastcgi.server = (\n ...\n )\n ...\n}\nYou can also run multiple Django installations on the same site simply by\nspecifying multiple entries in the fastcgi.server directive. Add one\nFastCGI host for each.
Cherokee is a very fast, flexible and easy to configure Web Server. It\nsupports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, SSI,\nTLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly\nencoding, Load Balancing, Apache compatible log files, Data Base Balancer,\nReverse HTTP Proxy and much more.
\nThe Cherokee project provides a documentation to setting up Django with Cherokee.
\nRegardless of the server and configuration you eventually decide to use, you\nwill also need to give some thought to how to serve the admin media files. The\nadvice given in the mod_wsgi documentation\nis also applicable in the setups detailed above.
\nBecause many of these fastcgi-based solutions require rewriting the URL at\nsome point inside the Web server, the path information that Django sees may not\nresemble the original URL that was passed in. This is a problem if the Django\napplication is being served from under a particular prefix and you want your\nURLs from the {% url %} tag to look like the prefix, rather than\nthe rewritten version, which might contain, for example, mysite.fcgi.
Django makes a good attempt to work out what the real script name prefix\nshould be. In particular, if the Web server sets the SCRIPT_URL (specific\nto Apache’s mod_rewrite), or REDIRECT_URL (set by a few servers, including\nApache + mod_rewrite in some situations), Django will work out the original\nprefix automatically.
In the cases where Django cannot work out the prefix correctly and where you\nwant the original value to be used in URLs, you can set the\nFORCE_SCRIPT_NAME setting in your main settings file. This sets the\nscript name uniformly for every URL served via that settings file. Thus you’ll\nneed to use different settings files if you want different sets of URLs to\nhave different script names in this case, but that is a rare situation.
As an example of how to use it, if your Django configuration is serving all of\nthe URLs under '/' and you wanted to use this setting, you would set\nFORCE_SCRIPT_NAME = '' in your settings file.