perl nginx fastcgi reverse-proxy plack

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



reverse-proxy plack (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 muy fácil agregar otra stanza de configuración a su configuración para que su aplicación esté en funcionamiento en unos pocos segundos. Nunca probé las diferencias de velocidad con ambas configuraciones, pero por otro lado, nunca tuve ningún problema en esa área, así que no puede ser tan malo.

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

Ha habido muchas dudas sobre por qué uno haría esto en general (por ejemplo, ¿Por qué usar nginx con Catalyst / Plack / Starman? ) Y las respuestas parecen aplicarse en ambos casos (por ejemplo, permitir que nginx sirva contenido estático, fácil reinicio de la aplicación servidor, balanceo de carga, etc.)

Sin embargo, estoy específicamente interesado en las ventajas y desventajas de usar FastCGI frente a un enfoque de proxy inverso. Parece que Starman es ampliamente considerado como la mejor aplicación y servidor de PSGI de Perl PSPI, y estoy luchando por ver alguna ventaja al usar FastCGI. Ambos enfoques parecen apoyar:

  • Sockets de dominio UNIX, así como sockets TCP
  • Los servidores de estilo de gestión de bifurcación / proceso también son servidores no bloqueados basados ​​en eventos (por ejemplo, AnyEvent).
  • Manejo de señal / reinicio elegante
  • PSGI

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

Entonces, ¿por qué elegirías uno sobre el otro?

Una configuración de proxy inverso (por ejemplo, nginx reenviando solicitudes HTTP a Starman) tiene las siguientes ventajas:

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

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

  • puede ser un buen compañero si también está utilizando algún tipo de orientación externa, almacenamiento en caché, proxy inverso (como Varnish o Squid), ya que permite omitirlo muy fácilmente.

Sin embargo, tiene las siguientes desventajas:

  • el servidor backend tiene que averiguar la IP original de origen, ya que todo lo que verá es la dirección del servidor frontend (generalmente localhost); hay casi una manera fácil de averiguar la dirección IP del cliente en los encabezados HTTP, pero eso es algo más que averiguar;

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

  • el frontend no puede generar automáticamente procesos de backend, como podría hacer con FastCGI, por ejemplo.

Elija sus pros / contras favoritos y haga su elección, supongo ;-)