traductor meaning python flask

python - meaning - Solicitudes lentas en el servidor local de Flask



flask wikipedia (7)

Estoy empezando a jugar con Flask en un servidor local y me doy cuenta de que los tiempos de solicitud / respuesta son mucho más lentos de lo que creo que deberían ser.

Solo un servidor simple como el siguiente toma cerca de 5 segundos para responder.

from flask import Flask app = Flask(__name__) @app.route("/") def index(): return "index" if __name__ == "__main__": app.run()

¿Algunas ideas? ¿O es así como es el servidor local?



La solución de @ sajid-siddiqi es técnicamente correcta, pero tenga en cuenta que el servidor WSGI incorporado en Werkzeug (que está empaquetado en Flask y lo que usa para app.run() ).

Instale un servidor WSGI para poder manejar el comportamiento de subprocesos múltiples. Hice un montón de investigación sobre varias actuaciones de servidor WSGI . Sus necesidades pueden variar, pero si todo lo que está usando es Flask , entonces recomendaría uno de los siguientes servidores web.

Para Python 2.x: gevent

Puede instalar gevent a través de pip con el comando pip install gevent . Las instrucciones sobre cómo modificar su código en consecuencia están aquí: http://flask.pocoo.org/docs/0.10/deploying/wsgi-standalone/#gevent

Para Python 3.x: meinheld

gevent es mejor, pero aún no se ha actualizado para usar python3 (consulte este hilo para obtener actualizaciones: https://github.com/gevent/gevent/issues/38 ). De todos los puntos de referencia que he visto que implican pruebas en el mundo real, Meinheld parece ser el servidor WSGI más simple y simplista. (También puede echar un vistazo a uWSGI si no le importa más configuración).

También puede instalar Meinheld a través de pip3 con el comando pip3 install meinheld . Desde allí, mira la muestra provista en la fuente de meinheld para integrar Flask : https://github.com/mopemope/meinheld/blob/master/example/flask_sample.py

* NOTA: Por mi uso de PyCharm , la línea from meinheld import server destaca como un error, pero el servidor se ejecutará, por lo que puede ignorar el error.


No tengo la reputación de comentar, así que lo agregaré como una "solución". Mi problema fue resuelto por "threaded = True", pero quiero dar algunos antecedentes para distinguir mi problema de otros para los cuales esto no puede hacerlo.

  1. Mi problema solo surgió cuando ejecuté Flask con python3. Al cambiar a python2, ya no tuve este problema.
  2. Mi problema se manifestó solo al acceder a la API con Chrome, en ese momento, Chrome mostró la pantalla esperada, pero todo lo demás colgó (curl, ffx, etc.) hasta que recargué o cerré la pestaña de Chrome, y en ese momento todo lo demás estaba esperando alrededor devolvió un resultado.

Mi mejor suposición es que Chrome estaba tratando de mantener la sesión abierta y Flask estaba bloqueando las solicitudes posteriores. En cuanto se detuvo o reinició la conexión desde Chrome, todo lo demás se procesó.

En mi caso, el hilo lo arregló. Por supuesto, ahora estoy repasando algunos de los enlaces que otros han proporcionado para asegurarme de que no va a causar ningún otro problema.


Obtuve este error cuando se ejecuta en hosts que no sean localhost , así que para algunos, los problemas subyacentes pueden presentar los mismos síntomas.

Cambié la mayoría de las cosas que he estado usando a Tornado, y anecdóticamente me ayudó una cantidad. He tenido algunas cargas de página lenta, pero las cosas parecen en general más receptivas. Además, es muy anecdótico, pero me parece notar que Flask solo se ralentizará con el tiempo, pero Flask + Tornado lo hará menos. Me imagino que usar Apache y mod_wsgi mejoraría las cosas, pero Tornado es realmente fácil de configurar (ver http://flask.pocoo.org/docs/deploying/others/ ).

(Además, una pregunta relacionada: la aplicación Flask cuelga ocasionalmente )


Ok, lo descubrí. Parece ser un problema con Werkzeug y os''s que soportan ipv6.

Desde el sitio de Werkzeug http://werkzeug.pocoo.org/docs/serving/ :

En los sistemas operativos que soportan ipv6 y lo tienen configurado, como los sistemas Linux modernos, OS X 10.4 o superior, así como Windows Vista, algunos navegadores pueden ser extremadamente lentos si se accede a su servidor local. La razón de esto es que a veces "localhost" está configurado para estar disponible en ambos sockets de ipv4 e ipv6 y algunos navegadores intentarán acceder primero a ipv6 y luego a ivp4.

Así que la solución es deshabilitar ipv6 del servidor local comentando la siguiente línea desde mi archivo de hosts:

::1 localhost

Una vez que hago esto, los problemas de latencia desaparecen.

Realmente estoy cavando Flask y me alegro de que no sea un problema con el framework. Sabía que no podría ser.


Tuve una solución diferente aquí. Acabo de eliminar todos los .pyc del directorio del servidor y lo inicié de nuevo. Por cierto, localhost ya estaba comentado en mi archivo hosts (Windows 8).

El servidor estaba congelado todo el tiempo y ahora funciona bien de nuevo.


threaded=True funciona para mí, pero finalmente descubrí que el problema se debe a foxyproxy en firefox. Desde que la aplicación del matraz se ejecuta en localhost, la respuesta lenta ocurre si

  • foxyproxy está habilitado en Firefox

la respuesta lenta no sucederá si

  • foxyproxy está deshabilitado en firefox

  • acceder al sitio web usando otros navegadores

La única solución que encontré es deshabilitar foxyproxy, intenté agregar localhost a la lista negra de proxy y ajustar la configuración, pero ninguno de ellos funcionó.