Clone this wiki locally
Most Tornado apps are run as single processes. For production, this usually means a fairly straight-forward combination of external process management and proxying. Here are some gathered best practices/resources.
When debug mode is enabled, templates are not cached and the app will automatically restart during development. This will fail if a Python syntax error occurs, however. (This can be worked around w/ some additional code or by using Supervisor in development)
Typically in production, multiple tornado app processes are run (at least one per core) with a frontend proxy. Tornado developer bdarnell has a tornado-production-skeleton illustrating this using Supervisor (process management) and nginx (proxying).
Traditionally, Tornado apps are single-process and require an external process manager, however HTTPServer can be run with multiple processes. Additionally, there are a couple additional helpers for helping out with managing multiple processes.
- Managing multiple Pylons apps with Supervisor - an excellent tutorial for getting started with Supervisor
- Deploy tornado application - short tutorial w/ Supervisor and nginx setup walkthrough
- supervisord-example.conf - this is an example cfg for running 4 tornado instances
- start-stop-daemon example - if you are running a standard Linux system this is an easy way to daemonize your Tornado app
- Upstart example - Upstart is built into Ubuntu and can respawn crashed instances.
As mentioned above, Tornado's HTTPServer can be configured for both multiple processes on a single or multiple sockets.
The official docs includes an example for running nginx as a load balancing proxy and for serving static files.
- Deploying Python web (Tornado) applications to multiple servers - short discussion on using a Load Balancer for live migration w/o downtime
- Rolling Deployment w/ Fabric
- Python Deployment Anti-Patterns
- buedafab - a nice collection of Fabric deployment scripts w/ EC2