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

Question

Una scelta molto popolare per l'esecuzione di applicazioni web Perl in questi giorni sembra essere dietro un server web nginx che inoltra richieste a un demone FastCGI oa un server Web abilitato PSGI (ad esempio, Starman) .

Ci sono stati un sacco di domanda sul perché si potrebbe fare questo in generale (ad es Why use nginx with Catalyst/Plack/Starman?) e le risposte sembrano applicarsi in entrambi i casi (ad esempio, permettono nginx per servire contenuti statici, semplice riavvio del server di applicazione, bilanciamento del carico , ecc.)

Tuttavia, sono specificamente interessato ai pro/contro dell'uso di FastCGI rispetto all'approccio del reverse-proxy. Sembra che Starman sia ampiamente considerato il più veloce e migliore application/server per PSGI Perl, e sto facendo fatica a vedere alcuni vantaggi nell'usare FastCGI. Entrambi gli approcci sembrano sostenere:

• socket di dominio UNIX costavano come socket TCP
• server forcella/Process Manager stile proprio come i server non-bloccanti basati su eventi (ad esempio AnyEvent).
• segnale movimentazione/graceful restart
• PSGI

Analogamente, la configurazione nginx per entrambe le opzioni è molto simile.

Quindi perché scegliere uno rispetto all'altro?

Answer 1

Una configurazione proxy inverso (ad esempio nginx inoltro richieste HTTP a Starman) presenta i seguenti vantaggi:

• le cose sono un po 'più facile per eseguire il debug, dal momento che si può facilmente colpire direttamente il server back-end;

• se hai bisogno di scalare il tuo server di backend, puoi facilmente usare qualcosa come libbra/haproxy tra il frontend (serving statico) HTTP ei tuoi backend (Zope viene spesso distribuito in questo modo);

• può essere un buon aiuto se si utilizza anche una sorta di proxy di inversione della cache, inversione della cache (come Varnish o Squid) poiché consente di bypassarlo molto facilmente.

Tuttavia, ha i seguenti aspetti negativi:

• backend server deve capire la vera origine IP, in quanto tutto ciò che vedrà è l'indirizzo del server di frontend (generalmente localhost); c'è quasi un modo semplice per scoprire l'indirizzo IP del client nelle intestazioni HTTP, ma è qualcosa in più da capire;

• il server di back-end non conosce generalmente l'intestazione HTTP "Host:" orignale e, pertanto, non può generare automaticamente un URL assoluto per una risorsa locale; Zope si rivolge a questo con URL speciali per incorporare il protocollo, l'host e la porta originali nella richiesta al back-end, ma è qualcosa che non si ha a che fare con FastCGI/Plack/...;

• il frontend non può generare automaticamente processi di backend, come per esempio con FastCGI.

Scegli i tuoi preferiti pro/contro e fate la vostra scelta, credo ;-)

Answer 2

HTTP è ben compreso dalla maggior parte degli amministratori di sistema ed è facile eseguire il debug. C'è quasi sempre una sorta di proxy inverso già implementato, quindi è un gioco da ragazzi aggiungere semplicemente un'altra stanza di configurazione alla sua configurazione per far funzionare la tua applicazione in pochi secondi. Mai provato le differenze di velocità con entrambe le impostazioni, ma d'altra parte non ho mai avuto problemi in quella zona, quindi non può essere così male.