nginx und Perl: FastCGI vs reverse proxy (PSGI/Starman)

Question

Eine sehr beliebte Wahl für die Ausführung von Perl-Webanwendungen scheint heutzutage hinter einem nginx-Webserver zu liegen, der Anfragen an einen FastCGI-Daemon oder einen PSGI-fähigen Webserver sendet (zB Starman) .

Es gab viele Frage gewesen, warum würde man im Allgemeinen dies tun (zB Why use nginx with Catalyst/Plack/Starman?) und die Antworten scheinen in beiden Fällen anzuwenden (zB erlauben nginx statische Inhalte, einfach Neustart des Anwendungsservers, Lastenausgleich zu dienen usw.)

Ich interessiere mich jedoch speziell für die Vor-/Nachteile der Verwendung von FastCGI gegenüber einem Reverse-Proxy-Ansatz. Es scheint, dass Starman weithin als der schnellste und beste Perl PSGI-Anwendung/Web-Server da draußen betrachtet wird, und ich habe Schwierigkeiten, irgendwelche Vorteile zu sehen, FastCGI überhaupt zu verwenden. Beide Ansätze scheinen zu unterstützen:

• UNIX Domain Sockets aswell als TCP-Sockets
• Gabel/Prozess-Manager-Server aswell als non-blocking ereignisbasierte (z AnyEvent) Servern.
• Signal Handling/ordnungsgemäßer Start
• PSGI

Ähnlich nginx-Konfiguration für beide Optionen sehr ähnlich ist.

Warum also würden Sie sich für eines entscheiden?

Answer 1

Ein Reverse-Proxy-Setup (z nginx Forwarding HTTP-Anfragen an Starman) hat folgende Vorteile:

• die Dinge ein wenig einfacher zu debuggen sind, da Sie ganz einfach direkt mit dem Backend-Server schlagen können;

• Wenn Sie Ihren Backend-Server skalieren müssen, können Sie leicht wie pound/haproxy zwischen dem Frontend-HTTP und Ihren Backends verwenden (Zope wird oft so implementiert);

• es kann ein netter Kumpel sein, wenn Sie auch eine Art von nach außen gerichteten, Caching, Reverse-Proxy (wie Varnish oder Squid) verwenden, da es sehr einfach umgehen kann.

Es hat jedoch folgende Nachteile:

• der Backend-Server die wirkliche Ursprung IP herauszufinden hat, da alle es sehen die Frontend-Server-Adresse (in der Regel localhost) ist; Es gibt fast eine einfache Möglichkeit, die Client-IP-Adresse in den HTTP-Headern zu finden, aber das ist etwas extra, um herauszufinden;

• Der Back-End-Server kennt den ursprünglichen HTTP-Header "Host:" nicht und kann daher nicht automatisch eine absolute URL für eine lokale Ressource generieren. Zope adressiert dies mit speziellen URLs, um das ursprüngliche Protokoll, den Host und den Port in der Anfrage in das Backend einzubetten, aber das ist etwas, was Sie nicht mit FastCGI/Plack/... tun müssen;

• Das Frontend kann nicht automatisch Backend-Prozesse generieren, wie es z. B. mit FastCGI möglich wäre.

Ihre Favoriten Profi Auswahl/Nachteile und Ihre Wahl treffen, ich denke ;-)

Answer 2

HTTP wird von den meisten Systemadministratoren gut verstanden und ist leicht zu debuggen. Es gibt fast immer eine Art Reverse-Proxy, der bereits implementiert ist. Es ist daher ein Kinderspiel, einfach eine Konfigurationszeile in die Konfiguration einzufügen, um die Anwendung in wenigen Sekunden zum Laufen zu bringen. Habe die Geschwindigkeitsunterschiede nie mit beiden Einstellungen getestet, aber auf der anderen Seite hatte ich nie Probleme in diesem Bereich, also kann es nicht so schlimm sein.