webserver - name - seo meta tags
Cuáles son las limitaciones del servidor web incorporado en el matraz (2)
Soy un novato en la administración de servidores web. He leído varias veces que el servidor web incorporado en el matraz no está diseñado para "producción" y debe usarse solo para pruebas y depuración ...
Pero, ¿qué ocurre si mi aplicación solo contacta con mil usuarios que ocasionalmente envían datos al servidor?
Si funciona, ¿cuándo tendré que preocuparme por la configuración de un servidor web más sofisticado? (Estoy buscando métricas aproximadas).
En pocas palabras, me encantaría encontrar lo que el servidor web incorporado puede hacer (con umbrales aproximados) y lo que no puede.
Muchas gracias !
El OP ya pasó de largo, pero para aquellos que se encuentren con esta pregunta en el futuro, solo agregaría que configurar un servidor Apache, incluso en una computadora portátil, es gratis y bastante fácil. Se puede configurar fácilmente para las pocas o tantas funciones que desee simplemente descomentando o comentando líneas en el archivo de configuración. Puede haber un método GUI aún más fácil para hacer eso en la actualidad, pero simplemente editar las configuraciones es simple.
No hay una respuesta correcta para esta pregunta, pero aquí hay algunas cosas que se deben tener en cuenta:
Con la cantidad correcta de escala horizontal, es muy posible que pueda seguir escalando el uso del servidor de depuración para siempre. Cuándo exactamente tendría que comenzar a escalar (o cambiar a usar un servidor web "real") también dependería del entorno en el que está alojado, las expectativas de los usuarios, etc.
El problema principal con el que probablemente se encuentre es que el servidor tiene un único subproceso. Esto significa que manejará cada solicitud de a una por vez, en serie. Esto significa que si intenta atender más de una solicitud (incluidos favicones, elementos estáticos como imágenes, archivos CSS y Javascript, etc.) las solicitudes tardarán más. Si se produce una demora prolongada en una solicitud determinada (digamos, 20 segundos), toda la aplicación no responde durante ese tiempo (20 segundos). Esto es solo el valor predeterminado, por supuesto: puede aumentar el número de subprocesos (o hacer que las solicitudes se manejen en otros procesos), lo que puede aliviar algunos problemas. Pero una vez más, aún puede ser lento bajo una carga "alta". Lo que se considera una carga "alta" dependerá de su aplicación y de las expectativas de un tiempo de respuesta máximo aceptable.
Otro problema es la seguridad: si a usted le preocupa en absoluto la seguridad (y no solo la seguridad de los datos en la aplicación en sí, sino la seguridad del cuadro que también la ejecutará), entonces no debe usar el servidor de desarrollo. No está listo para resistir ningún tipo de ataque.
Finalmente, el servidor de desarrollo podría simplemente fallar rotundamente. No está diseñado para ser utilizado como un proceso de larga duración (días, semanas, meses), por lo que no se ha probado que funcione en esta capacidad.
Entonces, sí, tiene limitaciones. Sí, todavía podrías usarlo en producción. Y sí, aún recomendaría usar un servidor web "real". Si no le gusta la idea de tener que instalar algo como Apache o Nginx, aún puede optar por una solución que sea tan fácil como "ejecutar un script de Python" utilizando algunos de los servidores independientes de WSGI , que pueden ejecutar un servidor que está diseñado para estar en producción con algo tan simple como ejecutar python run_app.py en la línea de comandos. Por lo general, solo necesita crear una secuencia de comandos python de 4-5 líneas para importar y crear el objeto del servidor, apuntarlo a su app Flask y ejecutarlo.
gunicornio podría ejecutarse con solo lo siguiente en la línea de comandos, no se necesita ningún script adicional:
gunicorn myproject:app
... donde "myproject" es el paquete Python que contiene el objeto Flask de la app .