UPDATE: For more performance info, James Abley pointed me to a very complete benchmark of available Python asynchronous webservers. It looks like Tornado is a real monster of concurrency.

There are already some how-to’s on the web on plugging Django web framework into Tornado webserver. A quick recap:

1. A tutorial on Tornado, Django and nginx by Jeremy Bowers.
2. How to import django framework inside a Tornado project by Lincoln Loop.
3. A snippet by lawgon.

My approach is slightly different as I wanted to run Tornado using Django management command-line interface.

The 3 easy steps are:

1. Add Tornado module to your django setup. If you use buildout, add Tornado git checkout to buildout.cfg using minitage.recipe.fetch recipe, like this:

   [buildout]
   ...
   parts =
   ...
       tornado
       django
   ...
   
   [tornado]
   recipe = minitage.recipe.fetch
   urls = git://github.com/facebook/tornado.git | git | | ${buildout:parts-directory}/tornado
   
   [django]
   recipe = minitage.recipe.scripts
   initialization =
       import os
       os.environ['DJANGO_SETTINGS_MODULE']='project.settings.development'
   scripts =
       django
   eggs =
       Django
       ...
   entry-points=
       django=django.core.management:execute_from_command_line
   extra-paths =
       ${buildout:directory}
       ${tornado:location}
   ...

2. Next, create a command-line extension hierarchy in your project’s main app:

   $ mkdir project/myapp/management
   $ touch project/myapp/management/__init__.py
   $ mkdir project/myapp/management/commands
   $ touch project/myapp/management/commands/__init__.py

3. Last, add a runtornado.py script in project/myapp/management/commands/ folder with the following content:

   from django.core.management.base import BaseCommand, CommandError
   from optparse import make_option
   import os
   import sys
   
   class Command(BaseCommand):
       option_list = BaseCommand.option_list + ()
       help = "Starts a Tornado Web."
       args = '[optional port number, or ipaddr:port]'
   
       def handle(self, addrport='', *args, **options):
           import django
           from django.core.handlers.wsgi import WSGIHandler
           from tornado import httpserver, wsgi, ioloop
   
   	sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
   	sys.stderr = os.fdopen(sys.stderr.fileno(), 'w', 0)
   
           if args:
               raise CommandError('Usage is runserver %s' % self.args)
           if not addrport:
               addr = ''
               port = '8000'
           else:
               try:
                   addr, port = addrport.split(':')
               except ValueError:
                   addr, port = '', addrport
           if not addr:
               addr = '127.0.0.1'
   
           if not port.isdigit():
               raise CommandError("%r is not a valid port number." % port)
   
           quit_command = (sys.platform == 'win32') and 'CTRL-BREAK' or 'CONTROL-C'
   
           def inner_run():
               from django.conf import settings
               print "Validating models..."
               self.validate(display_num_errors=True)
               print "\nDjango version %s, using settings %r" % (django.get_version(), settings.SETTINGS_MODULE)
               print "Server is running at http://%s:%s/" % (addr, port)
               print "Quit the server with %s." % quit_command
               application = WSGIHandler()
               container = wsgi.WSGIContainer(application)
               http_server = httpserver.HTTPServer(container)
               http_server.listen(int(port), address=addr)
               ioloop.IOLoop.instance().start()
   
           inner_run()

To run your tornado webserver, you just need to call your usual management program like manage.py with runtornado command, with the same syntax as runserver. In my case, I just run production server using supervisord, with a command like this:

$ ./bin/django runtornado --settings=project.settings.production 8000

If you found this quick how-to useful, remember to follow me on Twitter or subscribe to my feed for more django tips.

*~
*.orig
*.pyc
*.rej
.installed.cfg
__minitage__*
bin/*
develop-eggs
downloads
eggs
log
parts
project/media/uploads
tmp

As usual, feel free to post your additions as comments.

(Remixed by Matt Hamilton, original from http://xkcd.com/303)

You can find download and install instructions to start a buildout barebone here, however I will do a small recap:

First, check that your python installation has setuptools installed (platform-specific install instructions here).

Then run the following commands to create your new project and fetch bootstrapping script:

$ mkdir projectdir
$ cd projectdir
$ wget http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
$ mkdir downloads # this is needed, as buildout won't create it by itself.

Next step is writing buildout.cfg, an ini-style configuration file that specifies the setup for your deployment. The generic section is named “buildout” and its “parts” attribute refers to other sections that must be evaluated. I’ve created two parts: an example named “myproject”, which downloads, builds and installs a couple of fake eggs with wxPython in PYTHONPATH and a “wxPython” part, which downloads, builds and installs wxPython inside “parts” directory.

Each part is evaluated using a recipe, which is a plugin that is dynamically download from eggs repository or any other repository you pass through a find-links attribute. For my purposes I’ve employed two recipes from minitage project, a software deployment project developed by a nice french dude called kiorky (you can chat with him and obtain support at #minitage on irc.freenode.net).

[buildout]
download-cache = downloads
parts =
    wxPython
    myproject

[myproject]
recipe = minitage.recipe.egg
eggs =
    myegg
    myotheregg
extra_paths = ${wxPython:location}/lib/python

[wxPython]
recipe = minitage.recipe.cmmi
url = http://downloads.sourceforge.net/wxpython/wxPython-src-2.8.10.1.tar.bz2
post-make-hook = ${buildout:directory}/hooks.py:wxpython_post_make_hook
configure-options =
    --enable-debug --enable-debug_gdb # replace with --enable-optimize in production code
    --enable-display
    --enable-geometry
    --enable-graphics_ctx
    --enable-mediactrl
    --enable-sound
    --enable-unicode
    --with-libjpeg=builtin
    --with-libpng=builtin
    --with-libtiff=builtin
    --with-opengl
    --with-sdl
    --with-zlib=builtin
# Platform-dependent options, add as needed. Platform names are from sys.platform.lower().
configure-options-darwin = --with-mac --enable-monolithic
configure-options-linux2 = --with-gtk2

Configure-make-make-install recipe, namely minitage.recipe.cmmi, has a series of special options called “hooks” that allow extending the building process with non-standard actions through python code. I’ve added a call to wxpython_post_make_hook in hooks.py to deal with special post-install code:

import os
import sys
import subprocess

def wxpython_post_make_hook(o, b):
    return subprocess.call([sys.executable, 'setup.py',
        'WX_CONFIG=%s' % os.path.join(o['location'], 'bin', 'wx-config'),
        'BUILD_GIZMOS=0', 'BUILD_STC=0',
        'install', '--home=%s' % o['location'],
        ], cwd=os.path.join(o['compile-directory'], 'wxPython'))

Please note that I’ve disabled gizmos and stc support from wxPython, because I don’t need them and  they would require additional building in contrib.

Finally, launch the bootstrapping code:

$ python2.6 ./bootstrap.py

Of course, if you have a different version of python installed, adjust the command accordingly.

Now buildout is ready to be executed with:

$ ./bin/buildout

That’s all folks!