Based on Django paperwork Django could be set up with FastCGI.
Here's our setup (observe that I do not control Apache setup inside my place of work and I am needed to make use of FastCGI since finances it, instead of install WSGI):
The fcgi-relevant a part of our apache conf is:
LoadModule fastcgi_module modules/mod_fastcgi.so # IPC directory location # FastCgiIpcDir "/path/to/FastCGI_IPC" # General CGI config # FCGIConfig -idle-timeout 30 -listen-queue-depth 4 -maxProcesses 40 -minProcesses 10 -maxClassProcesses 2 -killInterval 60 -updateInterval 20 -singleThreshhold 0 -multiThreshhold 10 -processSlack 5 -failed-restart-delay 10 # To use FastCGI scripts: # AddHandler fastcgi-script .fcg .fcgi .fpl FastCgiServer "/path/to/my/django.fcgi" -listen-queue-depth 24 -processes 8 -restart-delay 1 -min-server-life 2 -failed-restart-delay 10
The final line ought to be best. My django.fcgi is:
#!/path/to/python-2.5/bin/python import sys, os open('pid', "w").write("%d" % (os.getpid())) # Add a custom Python path. sys.path.insert(0, "/path/to/django/") sys.path.insert(0, "/path/to/python2.5/site-packages/") # Switch to the directory of your project. (Optional.) os.chdir("/path/to/django/site") # Set the DJANGO_SETTINGS_MODULE environment variable. os.environ['DJANGO_SETTINGS_MODULE'] = "site.settings" from django.core.servers.fastcgi import runfastcgi runfastcgi(method="threaded", daemonize="false")
restarting the fcgi ought to be as easy as
however for us it does not create a restart (and that's why I am writing the pid's to files).
Why does not the touch django.fcgi work?
I'm not sure, however i can propose another solution that does not involve setting up anything:
Just run django on some arbitrary localhost port (say 50000), after which do that:
RewriteEngine On RewriteRule ^(.*)$ http://localhost:50000/$1 [P]
All it takes would be the standard mod_rewrite and mod_proxy.
Okay, a real response to your question, then. :)
Appears like you are missing a choice.
Causes mod_fastcgi to determine the modification duration of the applying on disk before processing each request. When the application on disk continues to be transformed, the procedure manager is informed and all sorts of running cases of the applying are wiped out off. Generally, it's preferred that this kind of functionality be built-to the application (e.g. every 100th request it inspections to ascertain if there is a more recent version on disk and exits if that's the case). There might be a superb problem (bug) if this choice is combined with -restart.