Why Does Tornado's Wsgi Support Block For More Than One Request?

Imagine the following tornado app: import logging import time from tornado import gen, httpserver, ioloop, web, wsgi def simple_app(environ, start_response): time.sleep(1)

Solution 1:

Tornado's WSGIContainer is not designed for high-traffic use. See the warning in its docs:

WSGI is a synchronous interface, while Tornado’s concurrency model is based on single-threaded asynchronous execution. This means that running a WSGI app with Tornado’s WSGIContainer is less scalable than running the same app in a multi-threaded WSGI server like gunicorn or uwsgi. Use WSGIContainer only when there are benefits to combining Tornado and WSGI in the same process that outweigh the reduced scalability.

In general it's best to run WSGI and Tornado applications in separate processes so the WSGI parts can have a server that is designed for WSGI. WSGIContainer should only be used when there are specific reasons to combine them in the same process, and then it should be used with care to avoid blocking the event loop for too long. It's best to do as much as possible in Tornado-native RequestHandlers so coroutines can be used instead of blocking.