As an alternative to a mod_python module, you might consider using the Mod_wsgi module, which has been developed more recently than the Mod_python development time and has been used in the Django community. A complete overview is beyond the scope of this book and you can find more information from the official Django documentation.
Deploying a Django app with fastcgi
Although using Apache and Mod_python to build a Django environment is most robust, on many virtual hosting platforms, it is often only possible to use fastcgi
In addition, in many cases, fastcgi can provide superior security and performance over Mod_python. For small sites, fastcgi is more lightweight than Apache.
How can a dynamic page request from a Web server be interpreted effectively by an external application? The answer is to use fastcgi!. Its work steps are described in a simple way:
Like Mod_python, FastCGI also resides in memory to return dynamic information to a customer request, and also to avoid the time spent starting a process like a traditional CGI. But the difference in Mod_python is that it does not run as a module within the same process as the Web server, but rather has its own independent process.
Why run code in a separate process?
In the traditional way of several mod_* embedded in the Apache script language (common example: Php,python/mod_python and Perl/mod_perl), They all embed themselves in the Apache process as an Apache extension module.
Each Apache process is a copy of an Apache engine that completely includes all of the features of Apache (even those that are not good for Django are loaded in). And fastcgi is not the same, it just put Python and Django and other essential things into memory.
According to FastCGI's own characteristics, you can see that the fastcgi process can run with the Web server's process separately under different user rights. For a multi-person shared system, this feature is very good for security, because you can safely share and reuse code with others.
If you want your Django to run in a fastcgi way, you must also install the Flup Python library, which is used to handle fastcgi. Many users complain that Flup's release is too long and is not always updated. Not really, they have been working hard, it is not released.
Run your FastCGI server
FastCGI is run as a client/server, and in many cases you have to start the FASTCGI service process yourself. Web servers (such as APACHE,LIGHTTPD, etc.) will only interact with your django-fastcgi process when there is a dynamic page access request. Because fast-cgi has always been in memory, it responds quickly.
On a virtual host, you may be forced to use the Web server-managed fastcgi process. In this case, see the section "Running Django in an Apache shared host" below.
The Web server has two ways of interacting with the fastcgi process: using a UNIX domain socket (named pipe in Win32) or using a TCP socket. Whichever you use, it depends on your preference, but TCP If the socket is not good, there will always be some permissions on the problem. What are choose is a manner of preference; A TCP socket is usually easier due to permissions issues.
Start your server project, first go to your project directory (where your manage.py file is located), and then use the manage.py runfcgi command:
./manage.py runfcgi [Options]
To learn how to use runfcgi, enter the manage.py runfcgi help command.
You can specify the socket or both host and port. When you want to create a Web server, you only need to point the server to the socket or host/port that you identified when you started the fastcgi server.
Run a thread server on the TCP port:
./manage.py runfcgi method=threaded host=127.0.0.1 port=3033
To run the Prefork server on a UNIX socket:
./manage.py runfcgi method=prefork Socket=/home/user/mysite.sock pidfile=django.pid
Started, but not as a background process (easier to debug):
./manage.py runfcgi Daemonize=false Socket=/tmp/mysite.sock
Stop FastCGI's trip
If your fastcgi is running in the foreground, simply press CTRL + C to stop the process easily. But if it's running in the background, you're going to use the UNIX kill command to kill it. However, when you are dealing with a background process, you will need to put it on the UNIX kill command
If you specify Pidfile this option in manage.py runfcgi, you can kill this fastcgi background process in this way:
Kill ' Cat $PIDFILE '
$PIDFILE is the one you specified in Pidfile.
You can use this script to easily restart the fastcgi daemon in Unix:
#!/bin/bash# Replace these three settings. Projdir= "/home/user/myproject" pidfile= "$PROJDIR/mysite.pid" socket= "$PROJDIR/mysite.sock" CD $PROJDIRif [-F $ Pidfile]; Then kill ' cat--$PIDFILE ' rm-f--$PIDFILEfi
Exec/usr/bin/env- pythonpath= ". /python: ". /manage.py runfcgi socket= $SOCKET pidfile= $PIDFIL