Configurare Apache per Massime Prestazioni

Apache è un’implementazione open-source del server HTTP. È il server web più popolare su Internet. Il Web Server Survey di dicembre 2005 condotto da Netcraft [

1 ] mostra che circa il 70% dei siti web su Internet utilizza Apache.

1. Prestazioni del server Apache

Le prestazioni del server Apache possono essere migliorate aggiungendo risorse hardware aggiuntive come RAM, CPU più veloci, ecc. Ma, nella maggior parte dei casi, lo stesso risultato può essere ottenuto tramite una configurazione personalizzata del server. Questo articolo esamina come ottenere il massimo delle prestazioni da Apache con le risorse hardware esistenti, specificamente sui sistemi Linux. Naturalmente, si presume che ci siano sufficienti risorse hardware, in particolare abbastanza RAM affinché il server non scambi frequentemente. Le prime due sezioni esaminano varie opzioni di configurazione Compile-Time e Run-Time. La sezione Run-Time presuppone che Apache sia compilato con

prefork

MPM. La compressione HTTP e la memorizzazione nella cache vengono discusse successivamente. Infine, si discute l’uso di server separati per servire contenuti statici e dinamici. Si presume una conoscenza di base della compilazione e configurazione di Apache e Linux.

2 Opzioni di Configurazione Compile-Time

2.1 Carica solo i moduli richiesti:

Il server HTTP Apache è un programma modulare in cui l’amministratore può scegliere le funzionalità da includere nel server selezionando un insieme di moduli [

2 ]. I moduli possono essere compilati staticamente nel binario httpd o possono essere compilati come Dynamic Shared Objects (DSO). I moduli DSO possono essere compilati quando il server viene costruito oppure possono utilizzare l’utilità

apxs

per compilare e aggiungere in un secondo momento. Il modulo mod_so deve essere compilato staticamente nel core di Apache per abilitare il supporto DSO.

Esegui apache con solo i moduli richiesti. Questo riduce l’impronta di memoria e quindi le prestazioni del server. Compilare staticamente i moduli salverà RAM utilizzata per supportare i moduli caricati dinamicamente, ma si deve ricompilare Apache ogni volta che un modulo deve essere aggiunto o rimosso. Qui il meccanismo DSO risulta utile. Una volta che il modulo mod_so è compilato staticamente, qualsiasi altro modulo può essere aggiunto o rimosso utilizzando il comando LoadModule nel file httpd.conf - naturalmente, dovrai compilare i moduli utilizzando apxs se non è stato compilato quando il server è stato costruito.

2.2 Scegliere l’MPM appropriato:

Il server Apache viene fornito con una selezione di Moduli di Multi-Processo (MPM) che sono responsabili del binding alle porte di rete sulla macchina, dell’accettazione delle richieste e dell’invio di processi figli per gestire le richieste [

3 ]. Solo un MPM può essere caricato nel server in un dato momento.

La scelta di un MPM dipende da vari fattori, come se il sistema operativo supporta i thread, quanta memoria è disponibile, scalabilità rispetto alla stabilità, se vengono utilizzati moduli di terze parti non thread-safe, ecc. I sistemi Linux possono scegliere di utilizzare un MPM a thread come worker o un MPM non a thread come prefork:

L’MPM Worker utilizza più processi figli. È multi-threaded all’interno di ciascun figlio e ogni thread gestisce una singola connessione. Worker è veloce e altamente scalabile e l’impronta di memoria è relativamente bassa. È ben adatto per più processori. D’altra parte, worker è meno tollerante ai moduli difettosi e i thread difettosi possono influenzare tutti i thread in un processo figlio.

L’MPM Prefork utilizza più processi figli, ciascun figlio gestisce una connessione alla volta. Prefork è ben adatto per sistemi a CPU singola o doppia, la velocità è comparabile a quella di worker ed è altamente tollerante ai moduli difettosi e ai figli che si bloccano. Ma l’uso della memoria è elevato, più traffico porta a un maggiore utilizzo della memoria.

3 Opzioni di Configurazione Run-Time

3.1 Ricerca DNS:

La direttiva HostnameLookups abilita la ricerca DNS in modo che i nomi host possano essere registrati invece dell’indirizzo IP. Questo aggiunge latenza a ogni richiesta poiché la ricerca DNS deve essere completata prima che la richiesta venga terminata. HostnameLookups è disattivato per impostazione predefinita in Apache 1.3 e versioni successive. Lascialo disattivato e utilizza un programma di post-elaborazione come logresolve per risolvere gli indirizzi IP nei file di registro degli accessi di Apache. Logresolve viene fornito con Apache.

Quando si utilizzano le direttive Allow from o Deny from, utilizzare l’indirizzo IP invece di un nome di dominio o di un nome host. Altrimenti, viene eseguita una doppia ricerca DNS per assicurarsi che il nome di dominio o il nome host non venga falsificato.

3.2 AllowOverride:

Se AllowOverride non è impostato su ‘None’, Apache tenterà di aprire il file .htaccess (come specificato dalla direttiva AccessFileName) in ogni directory che visita. Ad esempio:

DocumentRoot /var/www/html  
   
 AllowOverride all

Se viene effettuata una richiesta per l’URI /index.html, Apache tenterà di aprire /.htaccess, /var/.htaccess, /var/www/.htaccess e /var/www/html/.htaccess. Queste ulteriori ricerche nel file system aggiungono latenza. Se .htaccess è necessario per una particolare directory, abilitalo solo per quella directory.

3.3 FollowSymLinks e SymLinksIfOwnerMatch:

Se l’opzione FollowSymLinks è impostata, il server seguirà i collegamenti simbolici in questa directory. Se SymLinksIfOwnerMatch è impostato, il server seguirà i collegamenti simbolici solo se il file o la directory di destinazione è di proprietà dello stesso utente del collegamento.

Se SymLinksIfOwnerMatch è impostato, Apache dovrà emettere chiamate di sistema aggiuntive per verificare se la proprietà del collegamento e del file di destinazione corrispondono. Sono necessarie anche chiamate di sistema aggiuntive quando FollowSymLinks NON è impostato. Ad esempio:

 DocumentRoot /vaw/www/html   
    
 Options SymLinksIfOwnerMatch

Per una richiesta effettuata per l’URI /index.html, Apache eseguirà lstat() su /var, /var/www, /var/www/html e /var/www/html/index.html. Queste chiamate di sistema aggiuntive aggiungeranno latenza. I risultati di lstat non vengono memorizzati nella cache, quindi si verificheranno a ogni richiesta.

Per massime prestazioni, imposta FollowSymLinks ovunque e non impostare mai SymLinksIfOwnerMatch. Oppure, se SymLinksIfOwnerMatch è necessario per una directory, impostalo solo per quella directory.

3.4 Negoziazione dei contenuti:

Evita la negoziazione dei contenuti per una risposta rapida. Se la negoziazione dei contenuti è necessaria per il sito, utilizza i file type-map piuttosto che la direttiva Options MultiViews. Con MultiViews, Apache deve eseguire la scansione della directory per i file, il che aggiunge latenza.

3.5 MaxClients:

Il MaxClients imposta il limite sul numero massimo di richieste simultanee che possono essere supportate dal server. Non più di questo numero di processi figli vengono generati. Non dovrebbe essere impostato troppo basso in modo che nuove connessioni vengano messe in coda, il che alla fine scade e le risorse del server rimangono inutilizzate. Impostare questo valore troppo alto causerà l’inizio dello swapping del server e il tempo di risposta degraderà drasticamente. Il valore appropriato per MaxClients può essere calcolato come: MaxClients = RAM totale dedicata al server web / dimensione massima del processo figlio —- [

4 ] La dimensione del processo figlio per servire file statici è di circa 2-3M. Per contenuti dinamici come PHP, può essere intorno ai 15M. La colonna RSS in

"ps -ylC httpd --sort:rss"

mostra l’uso della memoria fisica non scambiata dai processi Apache in kilobyte.

Se ci sono più utenti concorrenti di MaxClients, le richieste verranno messe in coda fino a un numero basato sulla direttiva ListenBacklog. Aumenta ServerLimit per impostare MaxClients sopra 256.

3.6 MinSpareServers, MaxSpareServers e StartServers:

MaxSpareServers e MinSpareServers determinano quanti processi figli mantenere mentre si attende le richieste. Se MinSpareServers è troppo basso e arriva un insieme di richieste, Apache dovrà generare processi figli aggiuntivi per servire le richieste. Creare processi figli è relativamente costoso. Se il server è occupato a creare processi figli, non sarà in grado di servire immediatamente le richieste dei client. MaxSpareServers non dovrebbe essere impostato troppo alto, può causare problemi di risorse poiché i processi figli consumano risorse.

Regola MinSpareServers e MaxSpareServers in modo che Apache non debba generare frequentemente più di 4 processi figli al secondo (Apache può generare un massimo di 32 processi figli al secondo). Quando più di 4 figli vengono generati al secondo, un messaggio verrà registrato nel ErrorLog.

La direttiva StartServers imposta il numero di processi server figli creati all’avvio. Apache continuerà a creare processi figli fino a quando non viene raggiunta l’impostazione di MinSpareServers. Non ha molto effetto sulle prestazioni se il server non viene riavviato frequentemente. Se ci sono molte richieste e Apache viene riavviato frequentemente, impostalo su un valore relativamente alto.

3.7 MaxRequestsPerChild:

La direttiva MaxRequestsPerChild imposta il limite sul numero di richieste che un singolo processo server figlio gestirà. Dopo MaxRequestsPerChild richieste, il processo figlio morirà. È impostato su 0 per impostazione predefinita, il che significa che il processo figlio non scadrà mai. È appropriato impostarlo su un valore di alcune migliaia. Questo può aiutare a prevenire perdite di memoria poiché il processo muore dopo aver servito un certo numero di richieste. Non impostare questo valore troppo basso, poiché creare nuovi processi comporta un sovraccarico.

3.8 KeepAlive e KeepAliveTimeout:

La direttiva KeepAlive consente di inviare più richieste sulla stessa connessione TCP. Questo è particolarmente utile durante la fornitura di pagine HTML con molte immagini. Se KeepAlive è impostato su Off, allora per ogni immagine deve essere stabilita una connessione TCP separata. Il sovraccarico dovuto all’instaurazione della connessione TCP può essere eliminato attivando KeepAlive.

KeepAliveTimeout determina quanto tempo attendere per la prossima richiesta. Imposta questo su un valore basso, forse tra i due e i cinque secondi. Se è impostato troppo alto, i processi figli sono bloccati in attesa del client quando potrebbero essere utilizzati per servire nuovi client.

4 Compressione HTTP & Caching

La compressione HTTP è completamente specificata in HTTP/1.1. Il server utilizza il metodo di codifica gzip o deflate per il payload della risposta prima che venga inviato al client. Il client quindi decomprime il payload. Non è necessario installare alcun software aggiuntivo sul lato client poiché tutti i principali browser supportano questo. Utilizzare la compressione salverà larghezza di banda e migliorerà il tempo di risposta, gli studi hanno trovato un guadagno medio di compressione del 75,2 % [

5 ]. La compressione HTTP può essere abilitata in Apache utilizzando il modulo

mod_deflate

. Il payload viene compresso solo se il browser richiede la compressione, altrimenti viene servito contenuto non compresso. Un browser consapevole della compressione informa il server che preferisce contenuti compressi tramite l’intestazione della richiesta HTTP - “Accept-Encoding: gzip,deflate”. Quindi il server risponde con un payload compresso e l’intestazione di risposta impostata su “

Content-Encoding:  
gzip

Il seguente esempio utilizza telnet per visualizzare le intestazioni di richiesta e risposta:

bash-3.00$ telnet www.webperformance.org 80  
 Trying 24.60.234.27...  
 Connected to www.webperformance.org (24.60.234.27).  
 Escape character is '^]'.  
 HEAD / HTTP/1.1  
 Host: www.webperformance.org  
 Accept-Encoding: gzip,deflate  
   
 HTTP/1.1 200 OK  
 Date: Sat, 31 Dec 2005 02:29:22 GMT  
 Server: Apache/2.0  
 X-Powered-By: PHP/5.1.1  
 Cache-Control: max-age=0  
 Expires: Sat, 31 Dec 2005 02:29:22 GMT  
 Vary: Accept-Encoding  
 Content-Encoding: gzip  
 Content-Length: 20  
 Content-Type: text/html; charset=ISO-8859-1

Nel caching, una copia dei dati viene memorizzata sul client o in un server proxy in modo che non debba essere recuperata frequentemente dal server. Questo salverà larghezza di banda, diminuirà il carico sul server e ridurrà la latenza. Il controllo della cache viene effettuato tramite le intestazioni HTTP. In Apache, questo può essere realizzato tramite i moduli mod_expires e mod_headers. Inoltre, esiste la memorizzazione nella cache lato server, in cui i contenuti frequentemente accessibili vengono memorizzati in memoria in modo che possano essere serviti rapidamente. Il modulo mod_cache può essere utilizzato per la memorizzazione nella cache lato server, è stabile in produzione nella versione 2.2 di Apache.

5 Server separato per contenuti statici e dinamici

I processi Apache che servono contenuti dinamici richiedono circa 3M a 20M di RAM. Cresce per adattarsi al contenuto che sta servendo e non diminuisce mai fino a quando il processo non muore. Supponiamo che un processo Apache cresca fino a 20M per servire un contenuto dinamico. Dopo aver completato la richiesta, è libero di servire qualsiasi altra richiesta. Se arriva una richiesta per un’immagine, allora questo processo da 20M sta servendo un contenuto statico che potrebbe essere servito anche da un processo da 1M. La memoria viene utilizzata in modo inefficiente.

Utilizza un piccolo Apache (con il minimo di moduli compilati staticamente) come server front-end per servire contenuti statici. Le richieste per contenuti dinamici vengono inoltrate al pesante Apache (compilato con tutti i moduli richiesti). Utilizzare un server front-end leggero ha il vantaggio che i contenuti statici vengono serviti rapidamente senza un grande utilizzo di memoria e solo i contenuti dinamici vengono passati al server pesante.

L’inoltro delle richieste può essere realizzato utilizzando i moduli mod_proxy e rewrite_module. Supponiamo che ci sia un server Apache leggero in ascolto sulla porta 80 e il pesante Apache in ascolto sulla porta 8088. Quindi la seguente configurazione nell’Apache leggero può essere utilizzata per inoltrare tutte le richieste tranne quelle per le immagini al server pesante.

ProxyPassReverse / http://%{HTTP_HOST}:8088/  
 RewriteEngine on                                             ---- [9]  
 RewriteCond   %{REQUEST_URI} !.*\.(gif|png|jpg)$  
 RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]

Tutte le richieste, tranne quelle per le immagini, vengono proxy al server backend. La risposta viene ricevuta dal server front-end e quindi fornita al client. Per quanto riguarda il client, tutte le risposte sembrano provenire da un unico server.

6 Conclusione

Configurare Apache per massime prestazioni è complicato, non ci sono regole rigide e veloci. Comprendere i requisiti del server web e sperimentare con le varie opzioni disponibili. Utilizza strumenti come

httperf

per misurare le prestazioni del server web. Server leggeri come

tux ,

thttpd possono anche essere utilizzati come server front-end. Se viene utilizzato un server di database, assicurati che sia ottimizzato in modo da non creare colli di bottiglia. In caso di MySQL,

mtop può essere utilizzato per monitorare le query lente. Le prestazioni degli script PHP possono essere migliorate utilizzando un prodotto di caching PHP come

Turck MMCache . Elimina il sovraccarico dovuto alla compilazione memorizzando gli script PHP in stato compilato.

Bibliografia

1 http://news.netcraft.com/archives/web_server_survey.html

2 http://httpd.apache.org/docs/2.2/dso.html

3 http://httpd.apache.org/docs/2.2/mpm.html

4 http://modperlbook.org/html/ch11_01.html

5 http://www.speedupyoursite.com/18/18-2t.html

6 http://www.xs4all.nl/~thomas/apachecon/PerformanceTuning.html

7 http://www.onlamp.com/pub/a/onlamp/2004/02/05/lamp_tuning.html

8 http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

9 Linux Server Hacks di Rob Flickenger

Biografia dello scrittore: Vishnu Ram ha un MTech. in Sistemi di Comunicazione presso l’IIT Madras. È entrato a far parte di Bobcares nel 2003 e lavora per Poornam da allora.