Risposte:
Mi concentrerò sul comportamento lento del client e sul modo in cui la tua configurazione lo gestisce, ma non essere tentato di credere che sia l'unico vantaggio. Lo stesso metodo che avvantaggia i client lenti ha anche vantaggi per i client veloci, la gestione SSL, la gestione delle ondate di traffico e altri aspetti del servizio HTTP su Internet.
Gunicorn è un software pre-forking. Per le comunicazioni a bassa latenza, come il bilanciamento del carico al server delle app o le comunicazioni tra i servizi, i sistemi pre-fork possono avere molto successo. Non è previsto alcun costo per la creazione di un processo per gestire la richiesta e un singolo processo può essere dedicato alla gestione di una singola richiesta; l'eliminazione di queste cose può portare a un sistema complessivamente più veloce ed efficiente fino a quando il numero di connessioni simultanee supera il numero di processi disponibili per gestirle.
Nella tua situazione, hai a che fare con client ad alta latenza su Internet. Questi client lenti possono legare quegli stessi processi. Quando il QPS è importante, il codice dell'applicazione deve ricevere, gestire e risolvere la richiesta il più rapidamente possibile in modo che possa passare a un'altra richiesta. Quando i client lenti comunicano direttamente con il sistema, bloccano tale processo e lo rallentano. Invece di gestire e smaltire la richiesta il più rapidamente possibile, quel processo ora deve anche attendere il client lento. Il QPS effettivo diminuisce.
Gestire un gran numero di connessioni con pochissimi costi di CPU e memoria è ciò in cui i server asincroni come Nginx sono bravi. Non sono interessati nello stesso modo negativo dai client lenti perché sono abili nel gestire contemporaneamente un gran numero di clienti. Nel caso di Nginx, girando su hardware moderno può gestire decine di migliaia di connessioni contemporaneamente.
Nginx di fronte a un server di pre-fork è un'ottima combinazione. Nginx gestisce le comunicazioni con i clienti e non subisce penalità per la gestione di client lenti. Invia richieste al back-end il più rapidamente possibile per il back-end, consentendo al back-end di essere il più efficiente possibile con le risorse del server. Il back-end restituisce il risultato non appena lo calcola e Nginx esegue il buffering di tale risposta per alimentarlo a rallentare i client al proprio ritmo. Nel frattempo, il backend può passare a gestire un'altra richiesta anche se il client lento sta ancora ricevendo il risultato.
@blueben ha ragione. Un esempio specifico e comune di ciò che può accadere quando non viene utilizzato un proxy inverso è che un database back-end può esaurire gli handle di connessione al database in cui non esiste alcun proxy e c'è un picco di traffico. Ciò è dovuto al rilascio lento delle connessioni, come descritto da @blueben.
Un primo istinto a vedere l'esaurimento dei database potrebbe essere quello di supportare più connessioni al database. Ma aggiungendo un proxy inverso davanti all'app vedrai che il numero di connessioni al database richieste per un carico elevato diminuisce in modo significativo e si stabilizza; il livello di connessione al database non aumenterà quasi quanto quando c'è un picco di traffico.
Nginx è anche eccezionale nel servire contenuto statico, memorizzazione nella cache e varietà di altre attività HTTP, consentendo al server delle applicazioni di concentrarsi sull'essere un server app.