Perché ho bisogno di nginx quando ho uWSGI

62

Esistono molti tutorial su come configurare nginx per collaborare con uWGSI quando voglio distribuire l'applicazione Django.

Ma perché ho bisogno di nginx in questo kit? uSSGI stesso può servire applicazioni Python WSGI, può servire file statici, può anche fare SSL. Cosa può fare nginx che uWSGI non può fare?

nginx django uwsgi

— user983447
fonte

9

Vedo che questa domanda è chiusa come opinione. Non sono assolutamente d'accordo. Domanda "Cosa può fare nginx che uWSGI non può fare?" è basato sui fatti.

— user983447

1

In genere non parlo per riaperture, ma in questo caso sono d'accordo. La risposta esistente votata e accettata è buona, a dimostrazione del fatto che la domanda, come scritta, ammette risposte sensibili e pertinenti; Penso che probabilmente la renda una buona domanda.

— MadHatter,

55

Non

Questa è la risposta semplice, comunque: non ne hai bisogno . uWSGI è esso stesso un server capace.

Tuttavia, altri server come nginx sono in circolazione da più tempo e sono (probabilmente, comunque) più sicuri, oltre ad avere funzionalità aggiuntive non supportate da uWSGI - ad esempio, una migliore gestione delle risorse statiche (tramite qualsiasi combinazione di Expires o E-Tag header, compressione gzip, gzip precompresso, ecc.) che possono ridurre significativamente il carico del server e della rete; inoltre, un server come nginx davanti all'applicazione Django può implementare anche la memorizzazione nella cache del contenuto dinamico, contribuendo ulteriormente a ridurre il carico del server e persino a facilitare l'uso di una CDN (che normalmente non funziona bene con il contenuto dinamico ). Potresti anche andare oltre e disporre di nginx su un server completamente separato, invertendo le richieste di proxy per il contenuto dinamico su un cluster di server di applicazioni con bilanciamento del carico e gestendo il contenuto statico stesso.

Ad esempio, il mio blog (mentre è WordPress, ha nginx di fronte) è ottimizzato per memorizzare nella cache i post per 24 ore e per memorizzare nella cache le pagine dell'indice per 5 minuti; anche se non vedo abbastanza traffico perché ciò importi davvero per la maggior parte del tempo, aiuta il mio piccolo VPS a resistere all'ondata occasionale che altrimenti potrebbe abbatterlo - come la grande ondata di traffico quando uno dei miei articoli veniva scelto da un Twitterer con molte migliaia di follower, molti dei quali lo hanno twittato alle loro migliaia di follower.

Se avessi eseguito un server uWSGI "nudo" (e supponendo che fosse un sito Django, piuttosto che WordPress), avrebbe potuto resistere bene o potrebbe essersi schiantato e bruciato, costandomi in visitatori mancati . Avere nginx davanti a sé per gestire quel carico può davvero aiutare.

Detto questo, se stai semplicemente gestendo un piccolo sito che non vedrà molto traffico, non c'è davvero bisogno di nginx o altro - usa uWSGI da solo se è quello che vuoi fare. D'altra parte, se vedrai molto traffico ... beh, potresti comunque desiderare uWSGI, ma dovresti almeno considerare qualcosa davanti ad esso per aiutare con il carico. In realtà, dovresti davvero testare diverse configurazioni con il tuo sito finito per determinare cosa funziona meglio per te sotto il carico previsto e utilizzare tutto ciò che finisce per essere.

— Kromey
fonte

3

L'unica cosa che mi viene in mente che penso che valga la pena notare in aggiunta a ciò che @Kromey ha trattato nella loro risposta è che il protocollo nativo per uWSGI non è http ma il protocollo uwsgi. Il protocollo uwsgi è più semplice ed efficiente da gestire rispetto a http e quindi attaccare un server Web più completo (nginx o quant'altro) davanti all'applicazione uWSGI in realtà non duplica molta elaborazione e può offrire vantaggi significativi a seconda del tuo esigenze.

— Håkan Lindqvist,

@ HåkanLindqvist è assolutamente corretto; solo per chiarire, uWSGI è pienamente in grado di "parlare" HTTP, tuttavia, quindi può stare da solo bene, ma sì vale la pena notare che un server Web di fronte ad esso userebbe il protocollo uwsgi, non HTTP, per parlare con uWSGI, e quindi sì, pochissima duplicazione dell'elaborazione coinvolta.

— Kromey,

Questa è una buona risposta, tuttavia, potrebbe essere migliorata con un collegamento alla documentazione propria di uWSGI sull'argomento, che spiega con più dettagli cosa si può fare con uWSGI: uwsgi-docs.readthedocs.io/it/latest/…

— Tobias McNulty

1

IMO, se metti il tuo sito Web in Internet anziché in Lab, potresti vedere la differenza.

Immagina un utente di un altro paese con un browser Web aperto a bassa velocità di rete per accedere al tuo sito web. uWSGI gestirà quella connessione Http in un thread. Tale thread potrebbe impiegare molto tempo ad attendere una richiesta Http completa a causa della bassa velocità della rete. Se la dimensione del pool di thread è 100, immagina che a 100 utenti piaccia così lentamente, cosa accadrà? Nessun thread inattivo per gestire altre richieste HTTP.

Ma le cose sono abbastanza diverse per Nginx. Nginx è progettato in "Reactor Pattern". Potresti google "Reactor Pattern" per vedere come funziona. In breve, la connessione a bassa velocità non influisce sulla gestione di altre richieste HTTP.

— Jcyrss
fonte

1

Dubito che l'utilizzo di Nginx lo cambierà. Quando un'applicazione Django è ospitata su Apache utilizzando WSGI, la funzione di visualizzazione verrà chiamata prima che qualsiasi dato POST venga letto da un socket. Pertanto, se il client è lento, occuperà un thread dalla richiesta ricevuta fino alla ricezione dei dati POST. Perché sostituire Apache con Nginx cambierebbe questo?

— Kasperd,

1

Come noto, per impostazione predefinita, Nginx non eseguirà il proxy della richiesta HTTP per il back-end del server delle applicazioni fino a quando non riceverà una richiesta HTTP completa. Quindi per un server applicativo come Django, ciò che ottengono è sempre una connessione HTTP e una richiesta veloci, non c'è tempo da perdere in attesa di una richiesta http completa, dopo aver gestito presto la ricerca, il thread in esecuzione potrebbe essere inattivo per la prossima richiesta HTTP presto.

— Jcyrss,

1

Si chiama buffering delle richieste, che è abilitato di default in Nginx (nelle versioni precedenti di Nginx non era possibile disattivarlo): nginx.org/it/docs/http/…

— Tobias McNulty