Ciao, e benvenuto nella seconda puntata della trentacinquesima stagione. Nella scorsa puntata abbiamo capito cos'è un web server, il portiere che accoglie i visitatori di un sito. Oggi vediamo perché è nato nginx, e la sua storia ci porta dritti al problema che lo ha reso famoso, un problema che sembrava insormontabile: come fa un solo portiere ad accogliere decine di migliaia di visitatori tutti insieme, nello stesso istante? È un problema di scala, di traffico enorme, e i web server più vecchi non riuscivano a risolverlo. Oggi capiamo qual era questo problema, e perché il vecchio modo di lavorare crollava.
Partiamo dal ricordare che, agli inizi, i siti avevano poco traffico, perché è il punto di partenza. Quando il web era giovane, un sito riceveva pochi visitatori alla volta: qualche richiesta ogni tanto, poche connessioni contemporanee. Per gestire questa situazione, i primi web server adottarono un approccio semplice e naturale, che funzionava benissimo con quei numeri. Ma quel modo di lavorare, come vedremo, nascondeva un limite di fondo, che sarebbe esploso quando il web fosse cresciuto. Per capire il problema, dobbiamo prima capire come lavoravano quei primi web server, perché è lì che sta la radice della difficoltà.
Voglio spiegarti il vecchio modo di lavorare, perché è intuitivo ma rivelatore. I web server più vecchi lavoravano così: per ogni visitatore connesso, per ogni connessione aperta, dedicavano un lavoratore tutto suo. Immagina un addetto assegnato in esclusiva a ogni singolo visitatore, che si occupa solo di lui, dall'inizio alla fine. Un visitatore, un addetto dedicato. Con pochi visitatori alla volta, questo va benissimo: pochi visitatori, pochi addetti, tutto tranquillo. Ogni addetto segue il suo visitatore con calma, e la macchina regge senza problemi. È un modello semplice e ordinato, e per anni ha funzionato perfettamente, finché i numeri sono rimasti piccoli.
Ma ora voglio farti capire perché questo modello crolli quando i numeri diventano grandi, perché è il cuore del problema. Ogni addetto dedicato costa: occupa una fetta di memoria, delle risorse, anche quando non sta facendo granché. Con pochi addetti, il costo è trascurabile. Ma immagina di dover gestire non pochi visitatori, ma decine di migliaia di visitatori contemporaneamente, tutti connessi nello stesso istante. Con questo modello, serviranno decine di migliaia di addetti dedicati, uno per ciascuno. E decine di migliaia di addetti, ciascuno con la sua fetta di risorse, sono un peso enorme, insostenibile: la memoria si esaurisce, la macchina viene sommersa dal costo di tenere in piedi tutti quegli addetti, e crolla. Il modello dell'addetto per visitatore non regge i grandi numeri.
Voglio darti un'immagine che rende chiaro lo spreco di questo modello, perché è illuminante. Immagina un ristorante che assegna un cameriere dedicato a ogni singolo tavolo, un cameriere che resta lì, fermo accanto al suo tavolo, per tutta la cena. Con pochi tavoli, funziona. Ma con mille tavoli, ti servirebbero mille camerieri, uno fermo a ogni tavolo. E la cosa assurda è che, per gran parte del tempo, ogni cameriere non fa nulla: sta lì, fermo, ad aspettare che il suo tavolo abbia bisogno di qualcosa. Mille camerieri, quasi tutti fermi ad aspettare, occupano un'enormità di spazio e di stipendi per non fare quasi niente. È uno spreco colossale. Così lavoravano i vecchi web server: un lavoratore per connessione, quasi sempre fermo ad aspettare.
Voglio farti apprezzare quanto fosse reale e famoso questo problema, perché ha segnato la storia del web. Con la crescita esplosiva del web, i siti popolari si trovarono davvero a dover gestire decine di migliaia di connessioni simultanee. E il vecchio modello, un lavoratore per connessione, semplicemente non ce la faceva: le macchine venivano sommerse dal peso di tutti quei lavoratori. Questo divenne una sfida famosa e sentita: il problema di come gestire diecimila connessioni simultanee su una sola macchina. Era un muro che il vecchio modo di lavorare non riusciva a superare. E superare quel muro richiedeva non di lavorare di più, ma di ripensare completamente il modo in cui un web server gestisce le connessioni.
Ed ecco perché è nato nginx, che voglio farti apprezzare come la risposta a questo muro. nginx è stato creato proprio per risolvere questo problema: gestire un numero enorme di connessioni simultanee in modo efficiente, laddove i web server vecchi crollavano. Non è nato per fare cose che gli altri non facevano: è nato per fare la stessa cosa, ricevere e servire, ma a una scala che gli altri non reggevano, e con pochissime risorse. La sua ragion d'essere è tutta qui: rompere il muro delle diecimila connessioni. E per farlo, ha portato un'idea completamente diversa, un nuovo modo di gestire tantissime connessioni insieme, che vedremo nella prossima puntata, e che è il cuore della sua genialità.
Per oggi ci fermiamo qui. I web server più vecchi lavoravano dedicando un lavoratore a ogni singola connessione: un modello semplice, che funziona con pochi visitatori. Ma con decine di migliaia di connessioni simultanee, quel modello crolla: decine di migliaia di lavoratori dedicati, quasi tutti fermi ad aspettare, sommergono la macchina, come mille camerieri fermi a mille tavoli. Questa fu una sfida famosa: gestire diecimila connessioni simultanee. nginx è nato proprio per rompere questo muro, per reggere una scala enorme dove gli altri non ce la facevano, con un modo completamente diverso di lavorare. Nella prossima puntata vediamo quel modo: l'architettura a eventi. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.