Apache ed Nginx sono i due web server open source più utilizzati: insieme servono oltre il 50% del traffico internet.
Sebbene i due abbiano molte caratteristiche in comune, sarebbe un errore pensare che siano intercambiabili, è importante comprendere in quali situazioni usare l’uno o l’altro.
Apache
Apache HTTP Server è stato creato da Robert McCool nel 1995 e, dal 1999 è stato sviluppato sotto direzione della Apache Software Foundation. Dal 1996 Apache è il web server più popolare. Grazie a questa sua popolarità è disponibile una vasta documenazione. Originariamente, con Apache era possibile servire siti web dinamici solo attraverso i moduli, ogni modulo richiedeva molta memoria.
La principale differenza tra Nginx e Apache risiede nella gestione delle connessioni. Apache segue un approccio process-driven ovvero, ogni richiesta client viene elaborata da un processo separato (thread). Supponiamo sia presente un solo thread (single-threading), se bisogna elaborare richieste che necessitano di operazioni di scrittura e letuura, queste devono essere per forza essere elaborate sequenzialmente, prima una poi l’altra. Ogni richiesta rimane in coda fin quando non si finisce con la richiesta precedente. Per agirare l’ostacolo si possono avviare più processi single threading parallelamente, questo però richiede un uso elevato di risorse.
Si può ricorrere all’utilizzo di meccanismi multithreading. In questo caso, per ogni processo vengono attivati più thread, cosଠfacendo si riesce a compensare l’elevato fabisogno di risorse dell’architettura process-driven.
I meccanismi per l’elaborazione parallela si possono integrare sulle richieste client su Apache tramite uno dei tre moduli multi-processing (MPM): mpm_prefork, mpm_worker, mpm_event. Mediante questi moduli, Apache riesce a gestire le richieste in maniera concorrente, cioè risponde contemporaneamente a più richieste client tramite thread aggiuntivi.
Sia che si ricorra al multithreading o a più processi singlethread concorrenti, la domanda di risorse aggiuntive è elevata, un fattore che diventa limitante nell’ambito del ridimensionamento del server Apache.
A seconda di quale modulo venga utilizzato, Apache risolve un problema di concorrenza, cioè la risposta contemporanea di più richieste client, tramite processi aggiuntivi o thread.
L’enorme richiesta di risorse dell’approccio di un processo per connessione deriva dal fatto che per ogni processo aggiuntivo deve essere messo a disposizione un proprio ambiente di runtime. Ciò richiede l’assegnazione del tempo di CPU e della memoria separata. Inoltre ogni modulo Apache, che deve essere messo a disposizione in un processo worker, viene caricato separatamente per ogni processo. Invece i thread si spartiscono un ambiente di esecuzione (il programma) e lo spazio di indirizzamento nella memoria. L’overhead di thread aggiuntivi è cosଠnotevolmente inferiore rispetto a quello dei processi. Ma anche il multithreading richiede un’elevata capacità di calcolo, quando si tratta di commutazione di contesto (context switch).
Cerchi alternative a Google Adsense per il tuo sito? Prova TheMoneytizer! Usa il codice 189ed7ca010140fc2065b06e3802bcd5 per ricevere 5 € dopo l'iscrizione
In passato con Apache era possibile servire siti web dinamici solo attraverso i moduli. Ad esempio, per servire un sito web basato su PHP, Apache usava un modulo chiamato mod_php (modulo, che molti siti usano ancora oggi) e quel modulo usava molta memoria. In alternativa vengono utilizzati i meccanismi di multithreading. A differenza del single threading dove in ogni processo è a disposizione un unico thread per rispondere alle richieste del client, il multithreading dà la possibilità di attivare più thread nello stesso processo. Visto che i thread su Linux, essendo dei processi, hanno bisogno di meno risorse, il multithreading permette di compensare il grande fabbisogno di risorse dell’architettura basata sui processi del server Apache.
Il web server Apache segue un approccio in cui ogni richiesta client viene elaborata da un processo separato o thread. Nel caso di un unico thread (single threading), la modalità di funzionamento originaria del server Apache HTTP, sorgono prima o poi dei problemi di blocco delle periferiche I/O.
Nel 2002, Igor Sysoev ha iniziato a lavorare su Nginx come risposta al problema C10K, che rappresentava una sfida per i server web per iniziare a gestire diecimila connessioni simultanee come requisito per il web moderno. Il rilascio pubblico iniziale è stato realizzato nel 2004, raggiungendo questo obiettivo facendo affidamento su un’architettura asincrona events-driven. Nginx è cresciuto in popolarità sin dal suo rilascio grazie alla bassa richiesta di risorse di sistema e alla capacità di scalare facilmente. Nginx eccelle nel servire rapidamente contenuti statici ed è progettato per trasferire le richieste dinamiche ad altri software più adatti a tali scopi.
L’architettura event-drive di NGINX realizza la concorrenza senza processi o un thread aggiuntivi per ogni nuova connessione. Un singolo processo NGINX può elaborare migliaia di connessioni HTTP contemporaneamente. Questo viene realizzato tramite un meccanismo di cicli, il cosiddetto event loop. Ciò consente di portare a termine le richieste client asincronicamente all’interno di un thread.
Con Apache è possibile delimitare il numero dei processi attivi e dei thread, solo tramite valori minimi e massimi. Nginx regola il modello di processo sull’hardware che ha a disposizione, comprende un processo master, i processi di aiuto cache loader e cache manager, oltre che un numero di processi worker adattati al numero dei core del processore e stabiliti con precisione attraverso la configurazione.
Contenuti Statici e dinamici
Nginx è il migliore nel processare contenuti statici. Apache serve questo tipo di contenuti con un metodo file-based cioè salvandoli sul disco. L’architettura di Nginx risulta migliore nella gestione del carico ed è più veloce quando si tratta di servire contenuti statici. Secondo alcuni benchmark, in cui venivano avviate 1,000 connessioni simultanee, Nginx è 2.5 volte più veloce.
Nella gestione di contenuti dinamici, chi ha la meglio è Apache, infatti è in grado di eseguire gli script di un’applicazione internamente. Al contrario Nginx deve assegnare il processo di rendering ad un processo esterno, per poi ricevere in risposta il contenuto pre-processato (per esempio uno script PHP che genera una pagina web). Apache interpreta le richieste come risorsa fisica sul File System, o come un URL a cui inviare una risposta (ad esempio una pagina html).
Nginx, potendo essere usato sia come server web che come server proxy, lavora principalmente con gli URI, facendo da tramite tra il client e risorsa da esso richiesta.
Moduli
Entrambi permettono l’utilizzo di moduli esterni per estendere le proprie funzionalità . La differenza sta nel metodo utilizzato per caricare questi moduli nel proprio sistema. Apache consente di caricare i moduli in maniera dinamica, mentre il server è in esecuzione, il nucleo è sempre attivo e moduli possono essere attivati o disattivati in base alle specifiche esigenze.
Nginx non permette il caricamento dinamico dei moduli che devono essere selezionati e complilati nel sistema operativo. Seppur meno pratico, questo tipo di approccio non è poi cosଠmale. Consente comunque il caricamento di moduli non standard, inoltre rende il server più sicuro, visto che non gli si possono far caricare delle componenti arbitrarie.
Conclusioni
Nella sfida tra i due web server, non si riesce a decretare un vincitore. Tutto dipende dal compito da svolgere. Nginx ad esempio, è da preferire quando si devono restittuire contenuti statici di grosse dimensioni, che siano file o siti WordPress che usino bene la cache per velocizzare il caricamento delle pagine.
Altro fattore da considerare attentamente è la configurazione. Diffusa è la “credenza†che Apache consumi molta RAM, la cosa è vera solo nel caso in cui non venga configurato correttamente.
A dimostrazione di ciò, ci sono test che mostrano come Apache con mod_php riesca a funzionare meglio di Nginx con php-fpm.
Una buona idea, praticata da molti, è quella di sfruttare il meglio di uno e dall’altro, facendoli lavorare insieme. Una configurazione simile vede Nginx nel ruolo di Proxy. In questo modo si sfrutta la velocità di Nginx nel servire contenuti statici e la stabilità di Apache nella gestione dei contenuti dinamici.
Non esiste dunque un web server universale, che vada bene per ogni utilizzo, la soluzione ideale è quella che meglio si adatta alle nostre necessità .
Questo sito esiste da 4694 giorni (13 anni), e contiene ad oggi 4356 articoli (circa 3.484.800 parole in tutto) e 23 servizi online gratuiti. – Leggi un altro articolo a caso
Tutorial, approfondimenti tematici e notizie in ambito tecnologico (e non solo). Quanto scritto nell'articolo è un contributo di un collaboratore esterno, ed è da ritenersi puramente divulgativo - nè può sostituire il parere di un professionista dell'ambito. Credits immagini: pexels.com, pixabay.com, wikipedia.org, Midjourney, StarryAI, se non diversamente specificato. Questo articolo può contenere guide e/o indicazioni e/o pareri e/o suggerimenti non necessariamente provenienti dai brand citati (che vengono qui citati a scopo meramente divulgativo). Il punto di vista di questo articolo non coincide necessariamente con quello del proprietario dello stesso. Contattaci
Utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Lo facciamo per migliorare l'esperienza di navigazione e per mostrare annunci personalizzati. Il consenso a queste tecnologie ci consentirà di elaborare dati quali il comportamento di navigazione o gli ID univoci su questo sito. Il mancato consenso o la revoca del consenso possono influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.