nginx y Perl: FastCGI vs proxy inverso (PSGI/Starman)

Question

Una opción muy popular para ejecutar aplicaciones web Perl en estos días parece estar detrás de un servidor web nginx enviando solicitudes a un daemon FastCGI o un servidor web habilitado para PSGI (por ejemplo, Starman) .

Ha habido un montón de pregunta de por qué se podría hacer esto en general (por ejemplo Why use nginx with Catalyst/Plack/Starman?) y las respuestas parecen aplicar en ambos casos (por ejemplo, permitir que nginx para servir contenido estático, fácil reinicio del servidor de aplicaciones, balanceo de carga , etc.)

Sin embargo, estoy especialmente interesado en los pros/contras de usar FastCGI frente a un enfoque de proxy inverso. Parece que Starman es ampliamente considerado como el servidor web/aplicación Perl PSGI más rápido y mejor que existe, y estoy luchando para ver las ventajas de usar FastCGI en absoluto. Ambos enfoques parecen apoyar:

• sockets de dominio UNIX aswell como sockets TCP
• servidores del Gestor de estilos tenedor/proceso Aswell como servidores no bloqueantes basadas en eventos (por ejemplo AnyEvent).
• señal de manipulación/reinicio agraciado
• PSGI

Del mismo modo, la configuración nginx para cualquiera de las opciones es muy similar.

¿Por qué elegiría uno sobre el otro?

Answer 1

Una configuración de proxy inverso (por ejemplo nginx reenvío de peticiones HTTP a Starman) tiene las siguientes ventajas:

• cosas son un poco más fáciles de depurar, ya que fácilmente puede golpear directamente al servidor de fondo;

• si necesita escalar su servidor backend, puede usar fácilmente algo como libra/haproxy entre el frontend (servicio estático) HTTP y sus servidores (Zope se implementa a menudo así);

• puede ser un buen sidekick si también está utilizando algún tipo de proxy hacia el exterior, caché, reverso (como barniz o calamar), ya que permite evitarlo muy fácilmente.

Sin embargo, tiene los siguientes inconvenientes:

• el backend servidor tiene que averiguar la verdadera IP de origen, ya que todo lo que se ve es la dirección del servidor frontend (generalmente localhost); hay una manera casi fácil de encontrar la dirección IP del cliente en los encabezados HTTP, pero eso es algo extra para descubrir;

• el servidor de fondo generalmente no conoce el encabezado HTTP orignal "Host:" y, por lo tanto, no puede generar automáticamente una URL absoluta a un recurso local; Zope aborda esto con URL especiales para incrustar el protocolo original, el host y el puerto en la solicitud al backend, pero es algo que no tiene que ver con FastCGI/Plack/...;

• el frontend no puede engendrar automáticamente procesos back-end, como podría hacer con FastCGI, por ejemplo.

escoja a sus favoritos pros/contras y hacer su elección, supongo ;-)

Answer 2

HTTP es bien entendido por la mayoría de los administradores de sistemas y es fácil de depurar. Casi siempre hay algún tipo de proxy inverso ya implementado, por lo que es pan comido simplemente agregar otra sección de configuración a su configuración para poder poner su aplicación en funcionamiento en pocos segundos. Nunca probé las diferencias de velocidad con ambos ajustes pero, por otro lado, nunca tuve ningún problema en esa área, por lo que no puede ser tan malo.