Cosa succede quando un sito di Quiz diventa popolare ? Succede che bisogna gestire oltre 5000 visitatori al secondo per un totale di 50 mila connessioni al secondo. Come gestire soluzioni del genere ad alto traffico ? Alla base di tutto : WordPress con caching misto su memcached e Redis Server, PHP-FPM, Nginx con frontend Varnish dietro Cloudflare e Incapsula.
Questo articolo ha lo scopo di illustrare le potenzialità di un tuning ad-hoc di un server Linux al fine di servire oltre 5000 visitatori al secondo ad un blog WordPress.
Tutto quello che leggerete di seguito è frutto di un caso reale a cui abbiamo lavorato per garantire l’erogazione del servizio di hosting in modo ottimale, nel frattempo che i programmatori riscrivessero l’applicazione in un modo più performante, ovvero senza l’utilizzo di WordPress che per l’utilizzo e la tipologia di sito è sicuramente una scelta criticabile e sostituibile con del puro HTML e Javascript.
Alla fine dell’articolo un video, per chiunque preferisca vedere dal vivo alcuni passaggi importanti che sono solamente citati nell’articolo.
Introduzione alla vicenda
Il tutto nasce dalla richiesta di aiuto dello sviluppatore/sistemista di Quizdee.com noto sito di quiz online che mi riassume con un’immagine la situazione che avevano raggiunto : a 800 utenti al secondo il server si bloccava allocando tutta la potenza di calcolo delle 4 CPU istanziate su Amazon EC2.
Sin da subito veder girare httpd , sinonimo di Apache fa capire che c’è molto da fare. Un successivo sguardo alla configurazione di MySQL, ci mostra eloquentemente che non è stato fatto nulla di specifico nell’ottimizzazione ma che tutto gira come fornito dall’installazione.
Guardando l’applicativo non si può far altro che criticare la scelta “veloce” (ma funzionale) di usare WordPress per lo sviluppo di un sito Web che avrebbe potuto essere sviluppato su DBMS di tipo NOSQL come MongoDB o Redis, o meglio ancora eliminando completamente il lato server side, escludendo dunque PHP e MySQL per un corretto funzionamento.
Ovviamente riscrivere tutto da 0, avrebbe comportato tempistiche non gestibili in qualche giorno, per cui nel frattempo il compito era “tamponare” con soluzioni di emergenza in grado di reggere almeno 10 volte tanto gli 800 utenti iniziali, limite in cui il server linux iniziava letteralmente a morire sotto i click dei visitatori.
Cambio Hoster e cambio Server Dedicato.
Date le grosse risorse in termini di CPU abbiamo deciso di passare da un 4 core di Amazon EC2 a un server dedicato da Hetzner in Germania.
La scelta è ricaduta su un server di fascia alta :
Intel® Xeon® E5-1650 v2
Hexacore Ivy Bridge-E
6 core fisici e 12 logici.
128 GB di RAM ECC
2 Hard Disk SATA SSD a stato solido.
Connettività 1 Gbit/s
al modico costo di 139€ al mese IVA Inclusa.
Installazione e configurazione sistema operativo Linux CentOS 6
Abbiamo scelto di installare la famosa distribuzione CentOS, già precedentemente installata anche su Amazon EC2, e di procedere alla configurazione base, eliminando tutti i servizi non necessari e installando tutti i software voluti per una successiva configurazione. Abbiamo installato dunque :
- MySQL Server
DBMS relazionale, necessario al funzionamento di WordPress
- NGINX
nginx [engine x] e’ un server HTTP e reverse proxy, nonche’ un server mail proxy, scritto da Igor Sysoev. Per molto tempo e’ stato usato principalmente per alcuni siti russi ad alto carico, ad esempio Yandex, Mail.Ru, VKontakte e Rambler; in base ai dati di Netcraft, nell’ottobre 2013 nginx e’ il server HTTP o reverse proxy del 15.08% dei siti a maggiore carico.
- PHP-FPM in versione 5.5
è un frontend FastCGI per PHP che migliora le funzionalità di php-cgi.
- Zend OpCache
l’integrazione di Zend Optimizer+quale opcode cache; si tratta di un componente concepito per incrementare il livello di prestazioni nell’esecuzione delle applicazioni PHP senza alterarne i comportamenti.
- Memcached
è un sistema cache in RAM a oggetti distribuiti per migliorare la velocità .
Memcached diminuisce il tempo di caricamento delle pagine dei siti web dinamici basati su database mettendo in cache i dati richiesti e riducendo il carico sui server database
- Redis
un key-value store open source residente in memoria con persistenza facoltativa.
- Varnish
un acceleratore HTTP potente e open source, che è in grado di servire contenuti in cache in modo veloce
Per ogni software abbiamo proceduto ad effettuare un tuning ed una configurazione affichè tutto si integrasse perfettamente.
Obiettivi da raggiungere prefissati nella configurazione
Tra gli obiettivi da raggiungere che ci siamo prefissati, quello di minimizzare lo spawning di processi php-fpm e query MySQL. Sono loro a divorare i 12 processori logici, saturando tutte le risorse e accodando sempre più richieste fino ad una situazione di stallo.
Per far questo (non potendo nell’immediato riscrivere il tutto in un semplice HTML statico), dobbiamo cachare nel modo più corretto e veloce possibile quanto più si riesca a cachare in modo di restituire l’output html dalla RAM, piuttosto che generarne nuovamente da PHP e MySQL.
Oltretutto bisogna anche limitare il traffico dati delle immagini, che seppur poche in termini di quantità e di pesantezza riescono a generare circa 250 gigabyte al giorno di traffico.
Per i problemi di traffico abbiamo deciso di adottare 2 CDN (Content delivery network) che tramite una configurazione di reverse proxy possano cachare le nostre immagini sui loro server e fornirle al nostro posto risparmiandoci prezioso traffico dati.
La prima CloudFlare, si occupa di cachare i contenuti del sito www.quizdee.com, la seconda Incapsula, si occupa di cachare le immagini del dominio di terzo livello creato appositamente img.quizdee.com
La struttura finale ideale è simile alla seguente:
Cenni sulla configurazione dei vari componenti
In breve abbiamo configurato tutti i vari software precedentemente elencati per fornire un caching rapido e veloce dei contenuti. MySQL è stato impostato per cachare qualora richiesto moltissime query fino ad oltre 32 gigabyte di RAM.Valore sicuramente ben più elevato delle centinaia di megabyte in effettivo uso.
WordPress è stato configurato con il plugin W3 Total Cache (W3TC) al fine di cachare contenuti statici direttamente su memcached. Inoltre è stato abbinato anche a Redis, al fine di cachare post direttamente in RAM e diminuire i tempi di risposta fino a 100 volte tanto.
PHP-FPM è stato settato e configurato per gestire un massimo di 1000 connessioni contemporanee, numero in cui al di sopra saremmo andati incontro a sensibili problemi di carico.
NGINX è stato configurato ad hoc ottimizzandone alcuni parametri sui timeout e sul numero di thread gestibili.
Varnish è stato configurato come reverse Proxy su NGINX che a sua volta gestisce due virtual host www.quizdee.com e img.quizdee.com
Installazione e configurazione delle due CDN. Cloudflare ed Incapsula
Creati account gratuiti sulle due CDN, abbiamo impostato i DNS del dominio come consigliato dal pannello di controllo delle due CDN.
Cloudflare fornisce i contenuti di www.quizdee.com e Incapsula quelle di img.quizdee.com. Dopo alcuni minuti le richieste diminuivano sensibilmente e anche il load.
Questo è stato un passaggio se non vitale, comunque significativo considerando che in 4 giorni ci ha risparmiato di solo traffico immagini ben 740 GB, con oltre 27 milioni di hits, con picchi di banda di oltre 150 Mbit/s.
Risultati Ottenuti
I Risultati ottenuti sono stati quelli di riuscire ad erogare un servizio ad oltre 5000 utenti al secondo, avendo toccato anche dei picchi di oltre 8000, con il vantaggio di dare un’esperienza di usabilità reattiva e veloce, dunque maggiori risultati in termini di soddisfazione e relativi introiti.
Il costo è rimasto molto contenuto senza scalare su più macchine con load balancer che avrebbe significato una spesa fino a 10 volte tanto, tra noleggio dell’hardware e relativa configurazione più gestione managed dei server Linux.
Le statistiche di Google Analytics parlano chiaro : quasi 5000 utenti con appena 10 di carico sulla CPU.
Conclusioni
La potenza è nulla senza controllo. Ancora una volta, la dimostrazione pratica che buone capacità sistemistiche possano dare risultati eccellenti con costi veramente ridotti. Se hai un sito Web con molto traffico e vuoi ottimizzare le risorse con una configurazione su misura in base alle tue esigenze, contattaci pure.
