Una buona occasione per imparare

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! :)]]>