perl nginx catalyst plack starman

perl - ¿Por qué utilizar nginx con Catalyst/Plack/Starman?



(3)

Estoy tratando de implementar mi pequeña aplicación web Catalyst usando Plack / Starman. Toda la documentación parece sugerir que quiero usar esto en combinación con nginx. ¿Cuáles son los beneficios de esto? ¿Por qué no utilizar Starman directamente en el puerto 80?


Hice esta pregunta en #plack y obtuve la siguiente respuesta de @nothingmuch (agregué formato):

Con nginx puede configurar cosas de tipo loadbalancing / failover. Si el sitio es pequeño / simple, podría ser excesivo.

No sé de ninguna desventaja que Starman pueda tener. Quizás si tiene muchas visitas en archivos estáticos, nginx usaría menos CPU / memoria para manejarlas, pero es poco probable que sea significativo en una aplicación web típica. Sin embargo, las grandes descargas pueden atar a los trabajadores de Starman para descargas de archivos estáticos. (Quizás no, con sendfile.) Eso es todo lo que puedo pensar.

... Una configuración de conmutación por error puede ser agradable si desea realizar actualizaciones sin tiempo de inactividad. ("Falló" la versión anterior).


No tiene que ser nginx en particular, pero desea algún tipo de servidor frontend para su servidor de aplicaciones por algunas razones:

  1. Para que pueda ejecutar el servidor Catalyst en un puerto alto, como un usuario normal, mientras ejecuta el servidor frontend en el puerto 80.

  2. Para servir archivos estáticos (recursos ordinarios como imágenes, JS y CSS, así como cualquier tipo de descarga con la que desee usar X-Sendfile o X-Accel-Redirect) sin bloquear un proceso de Perl mientras dure la descarga .

  3. Hace las cosas más fáciles si quiere pasar a una configuración más complicada que involucra, por ejemplo, Edge Side Includes, o que el servidor web sirva directamente desde memcached o mogilefs (ambas cosas que nginx puede hacer), o una configuración load-balancing / HA.


Otra razón es que un servidor frontend liviano (incluso Apache está bien) consume mucha menos memoria por conexión que un proceso típico de Starman (un par de MB contra decenas o más de 100 MB). Dado que la conexión está abierta durante un tiempo, especialmente si desea utilizar conexiones keep-alive, puede admitir una gran cantidad de conexiones simultáneas con mucha menos memoria RAM. Solo asegúrese de que el tamaño del búfer del servidor de la interfaz de proxys sea lo suficientemente grande como para cargar una respuesta HTTP típica inmediatamente desde el back-end. Entonces el backend es libre de procesar la próxima solicitud.