Developing a site with Django is usually a breeze. You've set up your models, created some views and used some generic views, and you've even created some spiffy templates. Now it's time to publish that site for everyone to see. Now if you're not already familiar with Apache, Lighttpd, or Nginx, you're stuck trying to figure out complicated configuration files and settings directives. "Why can't deployment be just as easy as running the development server?", you scream.
It's tempting to just attempt to use the development server in production. But then you read the documentation (you do read the documentation, right?) and it clearly says:
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)
Looks like it's time to fire up Apache, right? Wrong. At least, you don't have to.
CherryPy to the Rescue
One of the features that CherryPy touts quite highly is that they include "A fast, HTTP/1.1-compliant, WSGI thread-pooled webserver", however a lesser known fact about that webserver is that it can be run completely independently of the rest of CherryPy--it's a standalone WSGI server.
So let's grab a copy of the CherryPy WSGI webserver:
wget http://svn.cherrypy.org/trunk/cherrypy/wsgiserver/__init__.py -O wsgiserver.py
Now that you've got a copy of the server, let's write a script to start it up. Your choices may vary depending on how many threads you want to run, etc.
import wsgiserver
#This can be from cherrypy import wsgiserver if you're not running it standalone.
import os
import django.core.handlers.wsgi
if __name__ == "__main__":
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
server = wsgiserver.CherryPyWSGIServer(
('0.0.0.0', 8000),
django.core.handlers.wsgi.WSGIHandler(),
server_name='www.django.example',
numthreads = 20,
)
try:
server.start()
except KeyboardInterrupt:
server.stop()
Consequences
Now you've got the server up and running, lets talk about some consequences of this approach.
- This is a multithreaded server. Django is not guaranteed to be completely thread safe. Many people seem to be running it fine in multithreaded environments, but thread safety may break at any time without notice. It might be an interesting project to convert cherrypy.wsgiserver to use processing instead of threading and see how the performance changes.
- This server is written in Python, and as with any other Python program, it will be difficult for it to match the speed of pure C. For exactly this reason, mod_wsgi is probably always going to be faster than this solution.
- You can have a completely self-contained server environment that can be run on Mac, Windows, and Linux with only Python and a few Python libraries installed. Distributing this wsgiserver.py script along with your Django project (or with a Django app, even) could be a great way of keeping the entire program self-contained.
Conclusion
Would I use this instead of a fully-featured web server like Apache or Nginx? Probably not. I would, however, use it for an intranet which demands more performance and security than the built-in development server. In any case, it's a nice nugget of information to have in your deployment toolbox.
All Content
Very cool. I've tried many times to delve into the world of apache and django, never very successful, this is a great alternative, thanks
what is so diffucult about apache conf?
It's not hard once you're used to it. But many people aren't used to it or don't have the time to learn. Hanging out in #django on FreeNode, you wouldn't believe how many times questions like this come up.
Two other options for Django in pure Python are the web servers in the Paste and eventlet libraries via their wsgi connectors. Paste is probably comparable to CherryPy; it's multithreaded and reasonably robust. The one in eventlet is built around some very clever networking code (similar to Twisted, but understandable by mere mortals) so it can handle thousands of requests with a single thread, but it's incomplete and undocumented.
Great post Eric! I've been putting together stand-alone one-click user installable Windows demos for a Django project, to date have been using the built-in server -- didn't realize CherryPy server integration was this simple. Thanks.
I was looking at full python stacks for hosting Django, and an interesting project I came across was the Aspen web server written in Python. It already has code for serving Django applications, and if memory serves me correctly it draws heavily from the CherryPy WSGI server. One drawback is that I'm not sure how active the development is right now, they had a release back in December 2007 but the mailing list seems pretty quiet. You can check it out at:
http://www.zetadev.com/software/aspen/
The idea of using CherryPy wsgi server to host Django/Python applications is always in my head. Good to know that somebody already took the first step.
I've used CherryPy as a production server plenty of times using mod_proxy and it really is a pretty robust solution. I'm not getting massive amounts of traffic, but I know others have used CherryPy in a similar configuration successfully.
I would also be happy if you could evaluate Aspen and provide a django python server startup script for it here..
Perhaps it is faster than cherrypy and using it for a standalone demonstration and intranet use, it would be great!
Also it would be nice if you would provide a option where someone do not have to set up the django enviroment variable..
Like the python manage.py runserver command, which also works if no environment variable is set manually!
Another option that relies in CherryPy as a built-in server is webpy.
Webpy is a very simple and lightweight option to Django and Turbogears.