Come funziona NGINX – Un’infografica per scoprirlo – 2

Un'infografica di NGINX spiega il funzionamento del server web ad alto livello, ponendo il luce le sue potenzialità rispetto a tutti gli altri concorrenti

Come funziona NGINX – Un’infografica per scoprirlo

Nel precedente post di questo articolo abbiamo introdotto NGINX sfruttando un’infografica che fornisce una panoramica di alto livello sul funzionamento del web server.  Dopo aver valutato il modello di processo e l’architettura, proseguiamo con il comprendere come avvenga lo scheduling della state machine e come avvengano gli aggiornamenti.

Scheduling della state machine in NGINX

Per quanto concerne il funzionamento di una state machine, ogni transazione HTTP può essere considerata come un gioco a scacchi. Da un lato della scacchiera vi è il web server che può prendere delle decisioni molto rapidamente. Dall’altra parte vi è il client remoto, il web browser che accede ad un sito o applicazione su una rete relativamente lenta. Le regole del gioco sono però moto complicate, in quanto entrano in gioco anche altri elementi con cui il web server potrebbe aver bisogno di comunicare.

Blocking state machine

La maggior parte dei web server o applicazioni per condurre il gioco di cui sopra utilizzano dei modelli di connessione process-per-connection o thread-per-connection. Ogni processo o thread contiene le istruzioni per giocare l’intera partita. Durante tutto il tempo il processo è gestito dal server che trascorre la maggior parte del suo tempo nello stato blocked, in attesa che il client completi la sua mossa.

nginx infografica 5

Il processo di funzionamento di una blocking state machine è il seguente:

  1. Il web server process resta in ascolto sui listen socket di nuove connessioni, come fossero nuove partite avviate dal client.
  2. Quando si riceve la richiesta di una nuova partita il web server inizia a giocare e successivamente si blocca in attesa di una risposta da parte del client.
  3. Una volta che la partita è stata completata il web server resta in attesa per comprendere se giungono nuove richieste da parte dello stesso client (keepalive connection). Qualora la connessione sia chiusa (il client va via o si verifica un timeout) il web server process si rende disponibile per iniziare nuovi giochi con altri client.

Si noti che ogni connessione HTTP attiva richiede un processo o un thread specifico. Questa architettura è molto semplice anche se comporta uno spreco di risorse.

NGINX è il Grande Maestro degli scacchi!

Avete mai sentito parlare di un giocatore di scacchi che è in grado di sfidare contemporaneamente decine di avversari? NGINX è il grande maestro in questo ambito, in quanto consente di giocare centinaia, anzi centinaia di migliaia di partite contemporaneamente.

nginx infografica 6

Il processo di funzionamento è il seguente:

  1. Ogni processo worker è in ascolto di un evento.
  2. Un evento sul listen socket significa che il client ha iniziato una nuova partita. Il worker process crea quindi una nuova connection socket. Un evento sul connection socket significa che il client ha giocato una nuova mossa e il worker è pronto a rispondere.

A differenza del caso precedente, il processo worker non attende di ricevere risposta, dopo aver fatto la sua mossa procede nel rispondere ad altre richieste e accoglie nuovi giocatori.

NGINX quindi scala molto bene per sostenere centinaia di migliaia di connessioni per ogni processo di lavoro

Come avvengono gli aggiornamenti di configurazione in NGINX

nginx infografica 7

L’aggiornamento della configurazione in NGINX è un processo davvero molto semplice. In genere basta ricorrere al comando

che controlla la configurazione su disco e invia un segnale di SIGHUP. Quando il processo master riceve questo segnale compie due azioni:

  1. Ricarica la configurazione e genera un nuovo insieme di worker process. Questi processi di lavoro iniziano ad accettare connessioni ed elaborano il traffico secondo la nuova configurazione.
  2. I vecchi process worker vengono chiusi pian piano. Per prima cosa i vecchi processi di lavoro non accettano più nuove connessioni. Non appena terminata ogni richiesta HTTP i worker chiudono ogni connessione. AL termine di questa prcedura il vecchio worker process esce dalla scena.

Questo processo può causare un piccolo picco sulla CPU e sulla memoria, ma in genere è impercettibile. È possibile ricaricare una configurazione anche più volte al secondo.

Per quanto concerne invece l’aggiornamento binario del software è possibile aggiornare NGINX senza alcuna connessione con tempi di inattività o interruzione del servizio minimi.

nginx infografica 8

Il processo di aggiornamento binario è molto simile all’aggiornamento della configurazione. Il nuovo processo di NGINX è eseguito in parallelo con il vecchio processo master finchè questo non termina pian piano la propria attività.

L’infografica fornita da NGINX è stata davvero molto utile per capire il funzionamento di questo web server e comprendere il lavoro di innovazione e ottimizzazione che da oltre 10 anni permette a NGINX di fornire le migliori prestazioni possibili nell’ambito dei web server.

Facci sapere cosa ne pensi!

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *