python - mac - Flask and Tornado Applciation no maneja múltiples solicitudes concurrentes

tornado python

Question

Estoy ejecutando una aplicación Flask simple con Tornado, pero la vista solo maneja una solicitud a la vez. ¿Cómo puedo hacer que maneje múltiples solicitudes simultáneas?

La solución que estoy usando es bifurcar y usar los múltiples procesos para manejar las solicitudes, pero no me gusta esa solución.

from flask import Flask

app = Flask(__name__)

@app.route(''/flask'')
def hello_world():
    return ''This comes from Flask ^_^''

from tornado.wsgi import WSGIContainer
from tornado.ioloop import IOLoop
from tornado.web import FallbackHandler, RequestHandler, Application
from flasky import app

class MainHandler(RequestHandler):
  def get(self):
    self.write("This message comes from Tornado ^_^")

tr = WSGIContainer(app)

application = Application([
    (r"/tornado", MainHandler),
    (r".*", FallbackHandler, dict(fallback=tr)),
])

if __name__ == "__main__":
    application.listen(8000)
    IOLoop.instance().start()

Answer 1

La respuesta inmediata es que debe usar un servidor WSGI dedicado, como uWSGI o Gunicorn, y configurarlo para que use varios trabajadores. No Tornado como un servidor WSGI.

Su solución de procesos de desove es correcta, ya que el uso de WSGI con Tornado es "correcto". WSGI es un protocolo síncrono: un trabajador maneja una solicitud a la vez. Flask no sabe nada de Tornado, por lo que no puede jugar bien usando corutinas: el manejo de la solicitud se realiza de forma sincronizada.

Tornado tiene una gran advertencia en sus documentos sobre esta cuestión exacta.

WSGI es una interfaz síncrona , mientras que el modelo de concurrencia de Tornado se basa en la ejecución asíncrona de un solo subproceso. Esto significa que ejecutar una aplicación WSGI con WSGIContainer de Tornado es menos escalable que ejecutar la misma aplicación en un servidor WSGI de subprocesos múltiples como gunicorn o uwsgi . Use WSGIContainer solo cuando haya beneficios en la combinación de Tornado y WSGI en el mismo proceso que superan la escalabilidad reducida.

En otras palabras: para manejar más solicitudes simultáneas con una aplicación WSGI, genera más trabajadores. El tipo de trabajador también importa: los hilos frente a los procesos frente a los eventos tienen desventajas. Está generando trabajadores creando procesos usted mismo, pero es más común usar un servidor WSGI como uWSGI o Gunicorn.