2010-09-03 21 views
10

Questa domanda non è nginx vs apache. Sono più interessato ai vantaggi architettonici di NGinx rispetto ad Apache. Come sono stato in grado di capire -server web nginx e apache

  • nginx è un server Web asincrono, basato su eventi, che supera Apache di un enorme margine.

Perché è questo? Dove rimane indietro Apache?

+0

Sei sicuro che Nginx sia puramente asincrono? –

risposta

13

Non esiste un singolo motivo per cui nginx "sovraperforma" Apache. Per molti modelli di carico è possibile configurare Apache in modo che gestisca questo carico. Per alcuni (molto occupati) modelli di carico, nginx nella configurazione di default può mostrare degrado delle prestazioni e può richiedere una regolazione fine per funzionare correttamente.

Tuttavia, è stata l'esperienza di molti, che nginx in realtà funziona "meglio", fuori dalla scatola, o con una semplice sintonizzazione. Le prestazioni di molti sistemi sono nettamente migliorate quando nginx è stato installato come front-end, con Apache spostato sul back-end.

Il motivo principale è che nginx è basato sugli eventi e contiene la macchina a stati che gestisce il ciclo di vita delle connessioni. In questo modo, puoi avere pochissimi processi "di lavoro", ognuno dei quali gestisce molte centinaia o persino migliaia di connessioni simultaneamente. Per Apache dovrai eseguire lo stesso numero di processi figli (o thread) come numero di connessioni.

È ovvio che tre processi contro un migliaio di processi dovrebbero essere una vittoria enorme, per lo meno.

In particolare, nginx consente di ridurre notevolmente il carico di file statici (immagini, Javascript, CSS). La gestione di ogni connessione aggiuntiva in nginx è molto economica, quindi, poiché i file statici sono solitamente la maggioranza in termini di numero di richieste, si ottiene un'elaborazione efficiente.

Inoltre, le prestazioni di nginx sono migliori per "client lenti". Quando Apache guarda direttamente a Internet, e i client inviano richieste su linee (congestionate), il tuo server (veloce) dovrà nutrire pazientemente il client (lento), in attesa fino a quando non consumerà l'intera risposta. Quindi il bambino (o il thread) Apache non può fare nulla di utile. D'altra parte, il lavoratore di Nginx mantiene semplicemente questa connessione lenta in un insieme di descrittori epoll, elaborando tutte le altre connessioni.

Dal punto di vista concettuale, si dovrebbe sempre cercare di separare le "classi" di richieste, con il proprio profilo di prestazioni e richieste. Ad esempio, servire piccoli file statici è una di queste classi; servire pagine dinamiche è un'altra di queste classi; servire enormi file statici è un altro. L'introduzione di nginx al tuo sistema gestisce implicitamente questa separazione.

+0

Quote: * Per Apache dovrai eseguire lo stesso numero di processi figli (o thread) come numero di connessioni. * Credo che questo non si applica se usi 'mpm_event'? –

+0

No, si applica anche a 'mpm_event' (dalla lettura di http://httpd.apache.org/docs/2.4/mod/event.html,' mpm_event' è semplicemente 'worker' con una svolta). Apache non ha un modulo FSM corretto. – squadette

+0

@squadette Dalla mia piccola lettura del codice 'mpm_event' non sono d'accordo: con' mpm_event' i worker sono usati solo per eseguire I/O quando il socket è pronto per farlo e per eseguire i gestori e i filtri, ad es. allo stesso modo i lavoratori sono usati in libevent (libevhtp), cherokee, ecc. Sotto 'mpm_event' puoi avere migliaia di connessioni con solo pochi lavoratori. – ArtemGr

Problemi correlati