Fine-tuning dei tempi di risposta

E' vero che i piccoli server web sono nella norma più che sufficienti per la gestione di alcuni siti, ma si devono rispettare molto più regole tecniche per renderli efficienti quanto i loro fratelli più grandi. Il lavoro di ottimizzazione potrebbe annullare il vantaggio economico, in quanto richiede tempi di osservazione prolungati e un accurato protocollo delle operazioni effettuate, per poter confrontare i risultati e determinare le cause del comportamento diverso.

Prima di tutto, i grafici automatici generati da Munin o da altri applicativi di monitoraggio sono ingrediente indispensabile per vedere le differenze di performance in base alla configurazione. Non vale assolutamente la percezione della velocità di navigazione dal browser, in quanto sono in gioco troppi fattori, fra i quali spiccano le tolleranze di linea, il carico del proprio PC ed eventuali invio o ricezione di file ed email, chat o quant'altro eseguito e dimenticato nello sfondo. Bastano pochi parametri per sballare i parametri di navigazione. Con i grafici invece abbiamo i risultati a lungo termine anche senza la nostra assistenza, e sono molto più attendibili della nostra immaginazione.



I dati di nostro interesse sono collocati nelle risorse di sistema con il colore verde, che rappresentano i cicli di elaborazione per far funzionare gli applicativi non direttamente accessibili dal web, come ad esempio l'Apache Web Server. Più alti sono questi valori, meno tempo resta agli script, e meno efficiente è il sistema.

L'impatto dell'utilizzo maggiore delle risorse di sistema è però molto maggiore in rispetto alle applicazioni web, qui indicato come user con il colore azzurro. Se il sistema è occupato oltre una certa soglia, del circa 1% della scala completa, la navigazione risulta difficile, perché fin quando è occupato il sistema, nessun altro processo potrà eseguire. Se le attese di sistema sono troppo lunghe, le connessioni scadono e i browser devono richiedere i file un'altra volta, che risulta in ulteriori rallentamenti e sovraccarichi, percepiti come la navigazione a scatti.

Le basse risorse dei piccoli server fanno esaurire i tempi di risposta più velocemente, e così è necessario intervenire sulla configurazione dello spazio web in modo ottimale. Nel grafico sopra si nota la crescita sproporzionata di risorse da un momento all'altro (alla coordinata X a 18.50), che perdura per qualche giorno fin quando non si sono modificate le impostazioni di Apache e in particolare, la configurazione del file .htaccess dei siti.

La natura del file .htaccess vuole che ogni richiesta web passi per la lettura di questo file, e più sono le richieste, più pesa la dimensione e l'efficienza di questo file. In questo caso abbiamo aggiunto terminatori alla fine delle istruzioni di redirect, che eseguono molto meno codice per ogni richiesta. Inoltre abbiamo cercato gli errori più frequenti nel file log degli errori, e inseriti per primi, perché la gestione degli errori mette il server web in uno stato speciale e molto più impegnativo in rispetto allo stato di normale esecuzione.

Ad esempio, il codice seguente mostra per tutte le immagini mancanti un file di minime dimensioni anziché generare un errore 404 ed è molto più efficiente, pur trattandosi di un'istruzione abbastanza complessa:
Il tag [L] nella istruzione finale indica al server Apache, che soddisfatte le condizioni precendenti può ignorare tutto il resto per ulteriori verifiche. Il codice funzionerebbe anche senza [L], ma genererebbe molto più carico inutile, che si esprime poi nella navigazione rallentata. Di conseguenza è molto utile studiare strategie migliori per amentare le prestazioni non solo del server nel suo insieme, ma anche del proprio sito.

Quando si sono assestate le configurazioni, è indispensabile trasferirle direttamente nella configurazione del server, in quanto più piccoli o assenti file .htaccess snelliscono oltre immaginazione il server e donano ai siti quel poco che basta per la navigazione senza attese presenti nella norma soltanto nei server grandi.