Apache vs NGINX - Chi VINCE in termini di prestazioni?

Apache vs NGINX è uno dei dibattiti più accesi in circolazione (sin dal rilascio di NGINX) perché entrambi sono uno dei server Web più comuni nella parola seguito da LiteSpeed ​​e OpenLiteSpeed.

Apache e NGINX alimentano quasi il 60% dei siti Web mondiali. Apache vs NGINX sono simili in termini di prestazioni e funzionalità. La loro architettura, sicurezza e prestazioni, d'altra parte, sono tutte diverse.

Può essere difficile scegliere tra questi due server perché sono entrambi eccellenti. Poiché ogni server Web ha la propria serie di vantaggi e svantaggi, è fondamentale rendere la migliore opzione possibile.

Puoi anche controllare il dibattito tra openlitespeed e nginx qui.

Confronto velocità Apache vs NGINX

Prima di approfondire il dibattito tra Apache e NGINX. Per prima cosa faremo un semplice test di velocità, in cui condurremo il test nei seguenti scenari.

• Proviamo un piccolo file statico di 5 KBytes
• File statico di dimensione 1 MB
• Testare una semplice applicazione PHP Hello World
• Analisi comparativa di Apache vs NGINX per WordPress

Abbiamo usato la stessa procedura per testare openlitespeed vs nginx. OpenLiteSpeed ​​è davvero un'ottima alternativa a NGINX perché supporta anche le regole di riscrittura .htaccess di base, quindi puoi passare facilmente da Apache a OpenLiteSpeed.

Proviamo un piccolo file statico di 5 KBytes

Verdetto finale : entrambi i server hanno funzionato allo stesso modo con un piccolo file statico.

Apache

NGINX

File statico di dimensione 1 MB

Verdetto finale : NGINX ha vinto chiaramente con un file statico di grandi dimensioni.

Apache

NGINX

Testare una semplice applicazione PHP Hello World

Verdetto finale : entrambi i server si sono comportati allo stesso modo con l'applicazione php hello world.

Apache

NGINX

Analisi comparativa di Apache vs NGINX per WordPress

Verdetto finale : NGINX ha vinto chiaramente con un sito WordPress. Puoi usare questa guida per velocizzare il tuo negozio WooCommerce

Apache

NGINX

Risultato del test - Apache vs NGINX

Come possiamo vedere nei test, NGINX è relativamente migliore di Apache in termini di velocità. I risultati sono:

1. Testare un piccolo file statico di 5 KBytes:

In questo test, vediamo che sia Apache che NGINX stanno dando gli stessi risultati relativi.

2. Testare un file statico di grandi dimensioni di 1 MB:

In questo test, vediamo che la velocità di NGINX è migliore di quella di Apache. NGINX sta dando un tempo di risposta medio molto inferiore.

3. Testare una semplice applicazione PHP Hello World

In questo test, stiamo vedendo che sia Apache che NGINX stanno dando gli stessi risultati relativi.

4. Test per Apache vs NGINX per WordPress

In questo test, vediamo che il tempo di risposta medio di NGINX è molto inferiore a quello di Apache, dandogli una velocità maggiore di quella di NGINX.

Apache

Esiste una comunità di sviluppatori che mantiene Apache come server web open source. Utilizza un'architettura basata sul processo in cui crea un nuovo thread per ogni richiesta di connessione.
Inoltre, Apache offre una varietà di moduli che possono essere utilizzati per aumentare la funzionalità del tuo server web. Apache è veloce, affidabile, sicuro e altamente personalizzabile per soddisfare le esigenze di diversi ambienti attraverso l'uso di estensioni e moduli.

Architettura di gestione delle connessioni

Apache ha una serie di moduli multi-elaborazione (chiamati MPM da Apache) che controllano come vengono gestite le richieste dei client. In sostanza, ciò consente agli amministratori di cambiare rapidamente l'architettura di gestione della connessione.

• mpm-Prefor: questo Multi-Processing Module (MPM) implementa un server Web pre-forking che non è threaded. Ciascun processo server può rispondere alle richieste in arrivo e la dimensione del pool di server è gestita da un processo padre. È adatto per i siti che devono evitare il threading per poter lavorare con librerie non thread-safe. È anche il miglior MPM per isolare ogni richiesta, assicurando che un problema con una non influisca sugli altri.
• mpm-worker: questo Multi-Processing Module (MPM) implementa un server multi-processo ibrido multi-thread. Può servire un numero elevato di richieste con meno risorse di sistema rispetto a un server basato su processi poiché utilizza i thread per consegnare le richieste. Mantenendo disponibili numerosi processi, ciascuno con molti thread, mantiene gran parte della stabilità di un server basato su processi.
• mpm-event: L'evento Multi-Processing Module (MPM) ha lo scopo di consentire la gestione di più richieste contemporaneamente delegando determinate elaborazioni ai thread del listener, liberando i thread di lavoro per servire nuove richieste.
  Apache ha un design flessibile che ti consente di scegliere tra una varietà di algoritmi di connessione e gestione delle richieste. Poiché il panorama di Internet è cambiato, le scelte presentate sono principalmente un prodotto dell'evoluzione del server e della maggiore richiesta di concorrenza.

Contenuti statici e dinamici

Il contenuto statico può essere gestito dai server Apache utilizzando i loro meccanismi standard basati su file. Gli approcci MPM sopra menzionati sono principalmente responsabili dell'esecuzione di queste procedure.

Apache può inoltre elaborare contenuto dinamico includendo un processore specifico del linguaggio in ciascuna delle sue istanze di lavoro. Ciò gli consente di eseguire contenuti dinamici senza l'uso di componenti esterni all'interno del server web. I moduli caricabili dinamicamente possono essere utilizzati per abilitare questi processori dinamici.

Poiché Apache può gestire internamente il contenuto dinamico, la configurazione dell'elaborazione dinamica è generalmente più semplice. I moduli possono essere prontamente sostituiti se i requisiti del contenuto cambiano e la comunicazione non ha bisogno di essere coordinata con un software aggiuntivo.

Configurazione distribuita e centralizzata

Analizzando e interpretando le direttive nei file nascosti all'interno delle cartelle di contenuto stesse, Apache aggiunge un'opzione per consentire un'ulteriore configurazione in base alla directory. I file .htaccess sono il nome di questi file.

Poiché questi file si trovano all'interno delle cartelle dei contenuti, Apache cerca un file .htaccess in ogni componente del percorso del file richiesto e applica le direttive ivi trovate. Ciò consente in modo efficace la configurazione decentralizzata del server Web, che viene comunemente utilizzato per la riscrittura degli URL, le limitazioni di accesso, l'autorizzazione e l'autenticazione e persino le politiche della cache.

Mentre tutti gli esempi precedenti possono essere impostati nel file di configurazione principale di Apache, i file .htaccess offrono una serie di vantaggi. Innanzitutto, poiché vengono valutati ogni volta che vengono incontrati lungo un percorso di richiesta, vengono implementati senza richiedere il ricaricamento del server. In secondo luogo, consente agli utenti non privilegiati di controllare porzioni specifiche del proprio contenuto Web senza concedere loro l'autorità completa sul file di configurazione.

Alcuni software Web, come i sistemi di gestione dei contenuti, possono ora personalizzare facilmente il proprio ambiente senza richiedere l'accesso al file di configurazione centrale. I provider di hosting condiviso lo utilizzano per mantenere il controllo della configurazione di base offrendo ai clienti l'accesso alle loro directory specifiche.

Interpretazione basata su file e URI

Apache può interpretare una richiesta come una risorsa fisica del filesystem o come una destinazione URI che richiede una valutazione più astratta. In generale, Apache usa i blocchi <Directory> o <File> per i primi, mentre i blocchi <Location> sono usati per risorse più astratte.

Poiché Apache è stato creato da zero per essere un server Web, interpreta le richieste come risorse del filesystem per impostazione predefinita. Per trovare un file vero e proprio, inizia con la radice del documento e aggiunge la parte della richiesta dopo l'host e il numero di porta. Sul web, la gerarchia del filesystem è essenzialmente rappresentata dall'albero dei documenti disponibile.

Quando la richiesta non corrisponde al filesystem sottostante, Apache offre una serie di opzioni. Una direttiva Alias, ad esempio, può essere utilizzata per eseguire il mapping a un luogo diverso. L'uso dei blocchi <Location> invece del filesystem consente di lavorare direttamente con l'URI. Sono inoltre disponibili variazioni delle espressioni regolari per applicare la configurazione in modo più flessibile nel filesystem.

Sebbene Apache possa funzionare sia sul filesystem sottostante che sullo spazio web, preferisce utilizzare tecniche di filesystem. Alcune delle decisioni di progettazione riflettono questo, come l'uso dei file .htaccess per l'impostazione per directory.

Modulo

Il sistema di moduli in Apache ti consente di caricare e scaricare dinamicamente i moduli per soddisfare le tue esigenze mentre il server è in esecuzione. Il core di Apache è sempre presente, ma i moduli possono essere abilitati o disabilitati, aggiungendo o eliminando funzionalità e collegandosi al server principale.

Questa funzione è utilizzata da Apache per un'ampia gamma di attività. A causa della maturità della piattaforma, viene fornita con un'ampia libreria di moduli. Mod php, ad esempio, incorpora un interprete PHP in ogni lavoratore in esecuzione e può essere utilizzato per modificare parti delle funzionalità essenziali del server.

D'altra parte, i moduli non gestiscono solo il contenuto dinamico. Possono riscrivere URL, autenticare client, rafforzare il server, registrare, memorizzare nella cache, comprimere, proxy, limitare la velocità e crittografare i dati, tra le altre funzioni. Possono offrire funzionalità avanzate senza aggiungere molto lavoro.

Supporto, Compatibilità, Ecosistema e documentazione

Poiché Apache è in circolazione da così tanto tempo, c'è molto supporto per questo. Per il server principale e le situazioni basate su attività che coinvolgono la connessione di Apache ad altri software, è disponibile una vasta libreria di documentazione proprietaria e di terze parti accessibile.

Molti strumenti e progetti Web contengono strumenti per eseguire il bootstrap all'interno di un ambiente Apache, oltre alla documentazione. Questo potrebbe essere fornito nei progetti stessi o nei pacchetti gestiti dal team di confezionamento della tua distribuzione.

A causa della sua quota di mercato e della quantità di tempo disponibile; Apache riceverà più supporto da progetti di terze parti in generale. È anche più probabile che gli amministratori abbiano lavorato con Apache, non solo per il suo uso diffuso, ma anche perché molte persone iniziano la loro carriera in ambienti di hosting condiviso, dove Apache è praticamente utilizzato esclusivamente a causa delle funzionalità di gestione distribuita .htaccess .

Vantaggi di Apache vs NGINX

Molti webmaster e sviluppatori preferiscono Apache su NGINX poiché è molto più vecchio. È compatibile con i sistemi operativi Windows, Unix e Linux.

• Per servire materiale dinamico, questa è una prestazione eccellente.
• Caricare e scaricare dinamicamente i moduli.
• Fornisce un file .htaccess per directory che può essere utilizzato per annullare le impostazioni a livello di sistema.
• Il supporto e la documentazione sono eccezionali.
• Il modello utilizza un approccio una connessione per processo.
• Include i moduli mod_evasive e mod_security, che aggiungono un ulteriore livello di sicurezza.

Svantaggi di Apache vs NGINX

• Impossibile gestire un numero elevato di richieste contemporaneamente.
• Rispetto a NGINX, ci vuole più tempo per visualizzare il contenuto statico.
• Fornisce ampie capacità di configurazione e gestione. Di conseguenza, non è appropriato per i principianti.
• I siti Web con molto traffico presentano problemi di prestazioni.

NGINX

Nel tentativo di superare il problema "C10k", il programmatore russo Igor Sysoev ha inventato NGINX. Igor ha raggiunto il suo obiettivo: NGINX può gestire facilmente più di 10.000 connessioni simultanee. Per gestire meglio le nuove connessioni, NGINX ha un design asincrono e guidato dagli eventi. NGINX è un server web che offre molte funzionalità. Di seguito ne elenchiamo alcuni:

• Una cache HTTP e un sistema di bilanciamento del carico
• Proxy front-end di Apache e altri server web.
• I protocolli HTTP, HTTPS, SMTP, POP3 e IMAP sono tutti serviti da questo server proxy inverso.

Dal suo rilascio, NGINX è diventato popolare grazie al suo basso utilizzo delle risorse e alla capacità di scalare efficacemente su hardware a basso costo. NGINX è un server web specializzato nel servire rapidamente materiale statico ed è progettato per inoltrare richieste dinamiche al software più adatto a tali attività.

Architettura di gestione delle connessioni

NGINX è arrivato sulla scena dopo Apache, con una migliore comprensione dei problemi di concorrenza che i siti su larga scala avrebbero dovuto affrontare. NGINX è stato creato da zero utilizzando un algoritmo di gestione della connessione asincrono, non bloccante e guidato dagli eventi per sfruttare queste informazioni.

NGINX genera processi di lavoro, ognuno dei quali è in grado di gestire decine di migliaia di connessioni. I processi di lavoro ottengono questo obiettivo sviluppando un meccanismo di loop rapido che controlla ed elabora gli eventi su base regolare. Disaccoppiando il lavoro effettivo dalle connessioni, ogni lavoratore può concentrarsi su una connessione solo quando si è verificato un nuovo evento.

Ciascuna delle connessioni del lavoratore viene inserita nel ciclo degli eventi, dove coesistono con altre connessioni. Gli eventi vengono elaborati in modo asincrono all'interno del ciclo, consentendo di eseguire il lavoro in modo non bloccante. Il collegamento viene eliminato dal ciclo dopo la chiusura.

NGINX può scalare eccezionalmente lontano con risorse minime grazie al suo metodo di elaborazione della connessione. Poiché il server è a thread singolo e non vengono generati processi aggiuntivi per gestire ogni nuova connessione, l'utilizzo della memoria e della CPU rimane relativamente costante, anche quando il server è sottoposto a forti pressioni.

Contenuti statici e dinamici

NGINX non ha il supporto nativo per l'elaborazione del contenuto dinamico. NGINX deve passare PHP e altre richieste di contenuto dinamico a un processore esterno per l'elaborazione e quindi attendere che il contenuto renderizzato venga restituito. Il cliente può quindi essere informato dei risultati.

Per gli amministratori, ciò implica che la comunicazione tra NGINX e il processore deve essere configurata utilizzando uno dei protocolli che NGINX comprende (http, FastCGI, SCGI, uWSGI, memcache). Questo può rendere le cose un po' più complicate, soprattutto quando si stima il numero di connessioni da consentire, perché ogni chiamata al processore richiederà una nuova connessione.

Questa strategia, d'altra parte, offre alcuni vantaggi. L'overhead dell'interprete dinamico sarà presente solo per il materiale dinamico perché non è incluso nel processo di lavoro. Il contenuto statico può essere inviato in modo semplice, con l'interprete consultato solo quando necessario. Ciò è possibile anche con Apache, ma elimina i vantaggi menzionati nella sezione precedente.

Configurazione distribuita e centralizzata

NGINX non comprende i file .htaccess e non ha un modo per valutare la configurazione per directory al di fuori del file di configurazione principale. Sebbene meno versatile dell'approccio Apache, ha i suoi vantaggi.

L'aumento delle prestazioni è il guadagno più evidente rispetto all'approccio .htaccess dell'impostazione a livello di directory. Per ogni richiesta, il server verificherà la presenza di questi file in ciascuna delle directory principali che portano al file richiesto in una configurazione Apache standard che consente l' .htaccess in qualsiasi directory. Se questa ricerca mostra uno o più file .htaccess , questi devono essere letti ed elaborati. NGINX può servire le richieste più velocemente eseguendo una singola query di directory e un file letto per ogni richiesta, non consentendo l'override delle directory (supponendo che il file si trovi nella struttura di directory convenzionale).

Un altro vantaggio è che è sicuro. La distribuzione dell'accesso alla configurazione a livello di directory estende anche le responsabilità di sicurezza ai singoli utenti, che potrebbero o meno essere attendibili per farlo correttamente. Assicurandoti che l'amministratore abbia il controllo completo sul server web, puoi evitare diversi errori di sicurezza che potrebbero sorgere quando l'accesso viene concesso ad altri.

Se sei preoccupato per questi problemi, tieni presente che potresti disabilitare l'interpretazione .htaccess in Apache.

Interpretazione basata su file VS URI

NGINX è stato progettato per funzionare sia come server web che come server proxy. Funziona in gran parte con gli URI, traducendosi nel filesystem quando necessario, a causa dell'architettura richiesta per questi due lavori.

Questo può essere visto nel modo in cui i file di configurazione NGINX vengono creati ed elaborati in alcuni casi.
NGINX non ha un modo per specificare la configurazione per una directory del filesystem, quindi analizza l'URI.

I blocchi del server e della posizione, ad esempio, sono i blocchi di configurazione più importanti per NGINX. Il blocco server è incaricato di interpretare l'host richiesto, mentre i blocchi di posizione sono incaricati di far corrispondere porzioni dell'URI dopo l'host e la porta. La richiesta viene ora elaborata come URI anziché come posizione del filesystem.

Tutte le richieste di file statici devono essere eventualmente mappate in una posizione sul disco. NGINX seleziona il server e i blocchi di posizione che elaboreranno prima la richiesta, quindi combina la radice del documento con l'URI, modificandolo secondo necessità in base alle impostazioni.

Può sembrare simile, ma interpretare le richieste principalmente come URI piuttosto che come posizioni del filesystem rende più facile per NGINX fungere da server Web, posta e proxy. NGINX viene impostato definendo come dovrebbe rispondere a determinati modelli di richiesta. NGINX non ispeziona il filesystem finché non è pronto a consegnare la richiesta, motivo per cui i file .htaccess non sono supportati.

Moduli

NGINX ha anche un sistema di moduli, tuttavia è considerevolmente diverso da quello di Apache. I moduli in NGINX non possono essere caricati dinamicamente, quindi devono essere scelti e compilati nel software di base.
Di conseguenza, NGINX diventerà molto meno adattabile per molti utenti. Ciò è particolarmente vero per gli utenti che sono riluttanti a mantenere il proprio software creato al di fuori dello schema di pacchettizzazione standard della loro distribuzione. Sebbene la maggior parte dei pacchetti delle distribuzioni includa i moduli più comunemente usati, se hai bisogno di un modulo non standard, dovrai creare tu stesso il server dal sorgente.

I moduli NGINX, d'altra parte, sono ancora piuttosto preziosi poiché ti consentono di specificare esattamente ciò che desideri dal tuo server includendo solo le funzionalità che desideri utilizzare. Alcuni utenti potrebbero anche ritenere che l'approccio sia più sicuro perché i componenti arbitrari non possono essere collegati al server. Se il tuo server viene mai messo in una situazione in cui ciò è concepibile, è quasi sicuramente già compromesso.

Molte delle stesse funzionalità sono disponibili nei moduli NGINX come nei moduli Apache. Il supporto proxy, la compressione, la limitazione della velocità, la registrazione, la riscrittura, la geolocalizzazione, l'autenticazione, la crittografia, lo streaming e le funzioni di posta sono tutti disponibili tramite i moduli NGINX.

Supporto, Compatibilità, Ecosistema e documentazione

NGINX sta guadagnando popolarità man mano che sempre più persone lo usano a causa delle sue alte prestazioni, ma ha ancora un po' di recupero da fare in alcune aree cruciali.

Poiché la maggior parte dello sviluppo e della documentazione iniziale era in russo, in passato era difficile trovare una documentazione sostanziale in lingua inglese per NGINX. La documentazione è stata arricchita man mano che l'interesse per il progetto è cresciuto e attualmente ci sono molte risorse amministrative disponibili sul sito NGINX e tramite terze parti.

Il supporto e la documentazione per le app di terze parti stanno diventando sempre più ampiamente disponibili e i manutentori dei pacchetti stanno iniziando a offrire opzioni per la configurazione automatica di Apache e NGINX in alcune circostanze. Configurare NGINX per operare con altri software è solitamente semplice anche senza supporto, purché le esigenze del progetto siano documentate (permessi, intestazioni, ecc.).

Vantaggi di NGINX

Il server web NGINX è semplice, leggero e veloce. Progettato specificamente per siti Web ad alto traffico.

• Utilizza un'architettura basata su eventi e non bloccante che utilizza meno CPU e memoria.
• Include molte opzioni di ottimizzazione e pubblicazione di contenuti statici. Di conseguenza, fornisce contenuto statico 2,5 volte più velocemente e utilizza meno memoria di Apache.
• Funziona in modo ammirevole in un sistema multiprocessore.
• Gli attacchi DDoS sono prevenuti da un'opzione di configurazione integrata.

Svantaggi di NGINX

• Il contenuto dinamico non può essere elaborato in modo nativo.
• È disponibile un numero inferiore di moduli.
• Sono supportati i sistemi operativi Linux e Unix, tuttavia il supporto di Windows è limitato.
• Il file .htaccess , che è supportato da Apache, non è supportato da NGINX.
• Una scarsità di software di monitoraggio dei registri: salva semplicemente i registri in file che devono essere esplorati manualmente.

Per utilizzare Apache e NGINX insieme

Dopo aver esaminato i vantaggi e gli svantaggi di Apache e NGINX, dovresti essere in grado di determinare quale server è più adatto alle tue esigenze. Molti utenti, tuttavia, ritengono che l'utilizzo di entrambi i server insieme consenta loro di sfruttare i vantaggi di ciascun server.

La configurazione standard per questa cooperazione consiste nell'usare NGINX come proxy inverso davanti ad Apache. Ciò consentirà a NGINX di elaborare tutte le richieste dei client. Ciò sfrutta la velocità di elaborazione rapida di NGINX e la capacità di gestire un numero elevato di connessioni contemporaneamente.

I file verranno forniti rapidamente e direttamente al client per il contenuto statico, in cui NGINX eccelle. NGINX invierà le richieste di contenuto dinamico, come gli script PHP, ad Apache, che elaborerà i risultati e fornirà la pagina sottoposta a rendering. Il materiale può quindi essere restituito al cliente tramite NGINX.

Per molti utenti, questo design funziona bene poiché consente a NGINX di fungere da smistatore. Gestirà tutte le richieste che può e trasmetterà quelle che non sa come gestire. Possiamo ridurre alcuni dei blocchi che si verificano quando un processo o un thread Apache è occupato riducendo il numero di richieste che il server Apache deve gestire.

Puoi scalare con questa disposizione aggiungendo più server back-end secondo necessità. NGINX può essere semplicemente configurato per inoltrare le richieste a un pool di server, migliorando la tolleranza agli errori e le prestazioni della configurazione.

Quando usare Apache vs NGINX?

Sia Apache che NGINX, come descritto in questo pezzo, sono server web potenti, adattabili e completi. Per i siti Web ad alto traffico, Apache è il migliore per fornire materiale dinamico, mentre NGINX è il migliore per fornire contenuto statico o flussi multimediali. È così semplice:

Quando puoi usare Apache

• Se utilizzi un piano di hosting condiviso.
• Se apprezzi una comunità utile con una moltitudine di risorse, questo è il posto dove stare.
• Apache è popolare tra gli sviluppatori web perché è semplice da configurare.

Quando puoi usare NGINX

• Se hai un VPS o un server dedicato.
• Sei il proprietario di un sito web popolare con molti contenuti statici.
• Se si desidera gestire il traffico in entrata e distribuirlo ai server upstream più lenti.

Apache vs. NGINX: quale dovresti scegliere per il tuo server nel 2022?

Qualunque sia la tua società di hosting fornita è quella che dovresti usare. In molte circostanze, non avrai un'opzione. Molti provider web seguono la stessa strategia, che dovresti seguire se stai decidendo tra Apache e NGINX:

• Apache è una buona scelta se si desidera ospitare un server che richiede una configurazione costante o se si desidera fornire agli utenti un'opzione di configurazione.
• NGINX, d'altra parte, è la strada da percorrere se desideri prestazioni super veloci, sicurezza solida e la possibilità di gestire le configurazioni anziché i tuoi utenti.

Grazie alla sua architettura fondamentale, Apache può occupare più RAM in termini di prestazioni. Nei casi ad alto traffico, NGINX funzionerà meglio, soprattutto se c'è molto materiale statico da gestire.

NGINX potrebbe quindi essere la soluzione ideale se fai affidamento sulla memorizzazione nella cache per archiviare e servire contenuti. Ricorda che NGINX non può fornire materiale dinamico; pertanto le tue prestazioni saranno influenzate dall'efficacia del proxy utilizzato dal tuo server.

Conclusione

Come puoi vedere, sia Apache che NGINX sono potenti, adattabili e capaci. Valutare le tue esigenze individuali e testare i modelli che ti aspetti di vedere sono i criteri principali per selezionare il server giusto per te.

Tra questi progetti, ci sono differenze significative in termini di prestazioni grezze, capacità e tempo necessario per implementarli. Spesso, però, sono il risultato di una serie di compromessi che non vanno ignorati. Ultimo ma non meno importante, non esiste un server web adatto a tutti, quindi scegli l'opzione più adatta alle tue esigenze.