Una buona occasione per imparare


In questi giorni sono stato assente da etechs. Ho avuto l’occasione d’imparare, di divertirmi e di aiutare.

Voglio infatti ringraziare Shor di Geekissimo per l’occasione.

Ma cos’ho fatto? Cos’è successo?

Il caso:
Geekissimo è un blog su piattaforma WordPress per la precisione è aggiornato alla versione 2.2, il blog è pieno pieno pieno di plugin, fa molto traffico ed è hostato su un server proprietario.

I problemi sono nati proprio su questo server, trattasi di una macchina collegata ad internet in america con 4 bei processoroni (4 CPU) Xeon, 4 Gb di Ram ed un bel po’ di hardDisk (in questo caso le dimensioni non contano molto) su cui è installata la distribuzione CentOS.
Nonostante le dimensioni notevoli della macchina, ed un blog solo che creava carico di lavoro, si piantava, andava in blocco apache e mysql con dei picchi di 200/300 utenti contemporanei, l’obbligo per l’amministratore a quel punto era il riavvio fisico della macchina.

Diagnosi:
WordPress è un’ottima piattaforma ma sinceramente mi sento di dire che non è prestante a livello server, infatti letteralmente brucia le risorse con una velocità impressionante.

Mysql piazzato costantemente tra il 270% edl il 300% di CPU e tutta la RAM mangiata per i 2 daemon principali Mysql ed Apache.
Prima di tutto Mysql non deve stare a livelli così alti.
Poi Apache va ottimizzato in base alle molte richieste simultanee.

Azione!
In due, dico DUE, giorni di lavoro sul server remoto siamo riusciti, con un po’ di analisi e di fortuna, ad ottenere notevoli risultati.

Giorno 1
Prima cosa riparazione ed Ottimizzazione delle tabelle! Fatto? Fatto!

Abbiamo messo mano al database creando indici e modificando alcuni parametri d’avvio lato server permettendo a mysql di fare caching di alcune query che venivano lanciate spesso.

Fare chaching delle query non è sempre La Soluzione, effettivamente il carico di lavoro andava comunque ripartito meglio.
Di fatto Mysql ha cominciato ad occupare meno memoria e tutto il sistema ne ha giovato.

Abbiamo abilitato wp-cache, una plugin che permette a WP di fare cache delle pagine, ovviamente fare cache delle paginifica perdere comunque un po’ di effetto on-line ma basta trovare il giusto compromesso e settare come expiration time 240 secondi che sarebbero 4 minuti. Infatti in un post/articolo i commenti, se la pagina è cachata, sono la cosa + dimanica, ma se noi postiamo un commento non ci aspettiamo quasi mai un’immediata risposta. Sulla base di questo ragionamento m’è sembrato giusto settare i 4 minuti.

Cachando (che brutto termine) le pagine non c’è bisogno nè di MySql nè di php perciò tutto il sistema ne giova, significa che per tutti quei contenuti che hanno una cache corrisponde un file statico sul server, apache deve solo redirezionare il contenuto. Bello no?

Già così si andava bene, e ne è scaturito l’articolo per l’ottimizzazione di WP presente su geekissimo (Grazzzzziieeeee). Io sono pignolo e la mia valutazione sulle prestazioni restavano ancora scarsotte.

Giorno 2
Otimizzazione di apache 1.3!!!!

E qui si comincia veramente sul serio. Manuali su manuali, guide, howTo, la guida ufficiale, qualche forum. Uno sbanderno d’informazioni, il processo di apache resta comunque molto delicato ed uno stop del servizio significa 200 utenti collegati che se ne vanno.

Questa giornata è stata particolarmente tesa, 3 down del blog, gente che tentava di collegarsi ad ogni secondo…. un vero inferno.

Ma alla fine geekissimo è in piedi e a me sembra abbastanza veloce. Apache è stato toccato server side, ho abilitato l’opzione del keeAlive e cercando di non sovraccaricare il server ho creato 20 server di start up, cioè 20 istanze apache che si attivano subito all’avvio.
Numero di server minimi 5, massimi 35.
Apache con l’opzione KeepAlive cerca di mantenere in piedi le istanze al posto di chiuderle, cosa che occuperebbe risorse CPU, accodando le richieste sulla stessa istanza. In questo modo non si chiudono e riaprono inutilmente le istanze, ma ci porta ad un’altro problema, se il primo client dell’istanza X di apache è lento, quelli in coda dovranno aspettare la fine del processo.

Potrebbe essere lento per colpa del DB, ma in questo caso nel Giorno 1 abbiamo snellito il server MySql, oppure semplicemente perchè la CPU è troppo occupata in altri processi.
La reazione a catena comunque è assicurata! Più lento diventa, più lento diventerà!
Altra nota importante è che Apache continuando ad elaborare pagine PHP per risolvere le richieste cresce di volume mangiando RAM come fossero le Gocciole della Mulino Bianco.

Come risolvere questo problema? Dobbiamo fare in modo che le istanze ad un certo punto si chiudano e si ricreino, nel caso in questione le 20 istanze iniziali durano si e no 2 minuti poi aumentano o calano a seconda del numero di connessioni istantanee.

MaxKeepAliveRequests è un parametro che indica all’istanza quante richieste si possono accodare per singola connessione d’istanza, di default è impostato a 0 che vuol dire illimitate, nel nostro caso non va bene, dobbiamo mettere un numero alto ma commisurato al tarffico a cui dobbiamo far fronte, 500 è un buon numero per geekissimo.
Inoltre MaxRequestsPerChild settato ad un 50 permette di chiudere l’istanza di Apache raggiunto il tetto e quindi di reinizializzare una nuova istanza più piccola in termini di RAM e fresca.
A questo punto dobbiamo tagliare le richieste più lente con il parametro KeepAliveTimeOut, più basso è meglio è, ovviamente se è troppo basso alcuni utenti riceveranno un errore 503, ma solo gli utenti più lenti o troppo lenti. Il risultato è che attualmente Geekissimo ha un utilizzo di processore del 5% per CPU e 30% di RAM utilizata in media.

In 3 giorni non si è mai piantato tanto da doverlo riavviare.

Mi ritengo abbastanza contento del risultato anche se non sono proprio del tutto soddisfatto, si può sempre migliorare.

Evviva il tuning! :)

Una buona occasione per imparare ultima modifica: 2007-10-17T00:00:00+00:00 da Enrico

14 Comments.

  1. Bravissimo, ottimo lavoro e ottima web reference!

  2. Mi associo al bravissimo – da queste attività si misura la differenza tra un professionista del web e un praticone che procede per tentativi. Il secondo NON sarebbe mai giunto ad una soluzione come la tua.

    Complimenti!

  3. ok sto diventando rosso!

  4. Ma dove diventi rosso? se lo sei già in nature, comunque complimenti, mi fai sentire orgoglioso di you

  5. oh oh oh
    il babbo!
    ragazzuoli il babbo m’ha scoperto :D

    grazie grazie grazie

  6. Ciao, noi stiamo avendo un po’ di problemi di ottimizzazione con la nostra vps. Abbiamo seguito il vostro tuning su geekissimo, cercando di adattarlo alla nostra situazione, ma abbiamo ancora un po’ di problemi che non riusciamo a risolvere. Il sito è http://www.tuxfeed.it se ti va di darci una mano a tempo perso, te ne saremmo grati (credo te ne sarà grata anche la nostra community…). Spero in un tuo solerte riscontro, complimenti per il lavoro che hai fatto con geekissimo. A presto!

  7. conosco molto bene tuxfeed ;)
    contattato al volo via mail

    Grazie per i complimenti

  8. Complimenti per il tuning e per la spiegazione di facile lettura e comprensione!

    Bravo!

  9. wè daniele occhio che mi abituo ai complimenti hehehe

  10. accipicchia che bel lavoro:) ne approfitto per chiederti se utilizzando wp-super-cache le cose non migliorini ulteriormente in quanto crea delle vere e proprie pagine statiche richiamate via htacess senza utillzzare php, e quindi mysql, in caso di cache gia presente. io la tengo a 3600 per la dinamica e 36000 per la superstatica.
    saluti.
    Ps il mio nokia ringrazia per l’accoglienza perfetta.

  11. @traffyk
    si vede bene sul nokia? mi fa piacere!
    wp-super-cache è ottimo, anche se con la 2.5 ho dovuto aggiornare e cambiare quelle 2 cosine su .htaccess, IMHO i 2 valori indicati da te sono un po’ altini,, però questo dipende da quanto traffico fai.

  12. Derosa - trackback on 10/03/2010 at 5:34 am

Trackbacks and Pingbacks: