ServerPlanrealizza una infrastruttura efficiente per una testata giornalistica nazionale, velocizzando gli accessi e ottimizzando funzionalità e risorse. Il rinnovamento del servizio è stato richiesto dal cliente per meglio gestire i flussi di traffico e i picchi periodici. Il portale informativo registra infatti un traffico di circa 3 milioni di pagine al mese e fino a 20mila utenti contemporaneamente connessi al sito.
L’architettura si basa su WordPress 5.2.2, ulteriormente personalizzata attraverso 24 plug-in e un tema custom. Il peso del sito è quantificato in circa 400 GByte. Al suo interno, il database è stato realizzato tramite 101 tabelle con circa 17 milioni di record, per un totale di 25 GByte di dati.
ServerPlan è intervenuta proponendo la suddivisione dei carichi su tre differenti server fisici. La prima macchina esegue i software Varnish 5.2 e Haproxy 1.5 e si occupa delle funzioni Frontend Proxy HTTPS e Frontend Cache HTTP. In questo caso si è scelto un server SuperMICRO X10SLD-F con CPU Intel Xeon E3-1231 v3 a 3,40 GHz, affiancato da 16 GByte di RAM e un array storage RAID 1 con due unità Solid State 120 GByte cadauna. Il sistema operativo è Linux CentOS 7.x 64.
Lo Stack LAMP e lo spazio di archiviazione dei dati sono gestiti attraverso un server Dell R440 con CPU Xeon Silver 4114 a 2,20 GHz e 64 GByte di RAM. In questo caso il RAID hardware, sempre di tipo mirroring, si basa su unità da 960 GByte SSD. La macchina esegue principalmente le componenti: Pannello cPanel, Apache 2.4, PHP 7.2 con Opcache in modalità FastCGI.
Per l’orchestrazione dell’articolato database si è scelto di adottare un server dedicato Dell 630 (Intel Xeon E5-2680 v4 a 2,40 GHz – 256 GByte di RAM – RAID 1 960 GByte SSD). La macchina esegue Linux CentOS 7.x 64 e MySQL 5.6.
Grazie a questa infrastruttura progettata da ServerPlan, il cliente può gestire tutte le funzionalità di hosting tramite l’unica macchina cPanel e il pratico pannello di controllo. Il sistema permette di caricare i dati tramite FTP/FTPs/SSH e di amministrare il database (phpMyAdmin) attuale e di crearne di aggiuntivi.
L’intero database di WordPress, considerando l’enorme numero di record, è stato convertito con motore InnoDB: lo stesso è stato ottimizzato sul DB server, in modo da utilizzare al massimo il processore e la RAM a disposizione. Questa conversione ha permesso di raggiungere performance molto alte anche sul back-end di WordPress.
Il traffico pubblico in HTTPS arriva sul server di frontend ed è gestito da haproxy (il certificato SSL è configurato localmente). Haproxy si occupa di inoltrare il traffico sulla porta 80 al servizio Varnish: quest’ultimo, come da configurazione, invia per la prima volta le richieste al back-end sul server Apache. In questa fase, Apache riceve la richiesta e invia nuovamente i dati a Varnish che, a sua volta, è in grado di inoltrarli all’utente e di salvare in RAM i risultati dell’attività. In questo modo, alle successive richieste per la medesima risorsa (immagini, CSS, pagina, etc.) è possibile rispondere accedendo direttamente a quanto memorizzato in RAM, senza passare per il webserver.
L’intero processo è stato messo a punto per ottimizzare le risorse dei server, ridurre il traffico ridondante e per ridurre i tempi di risposta del sito Web. Per esempio, le richieste di tipo Post (invio informazioni da parte dell’utente tramite il browser usando un form di contatto) non vengono salvate in cache, ma passano direttamente al back-end Apache.
WordPress, tramite un plug-in appositamente installato, effettua la cancellazione (flush) della cache di Varnish in automatico, nel caso in cui un redattore effettui modifiche (nuovo articolo, modifica articolo, modifica impostazioni WordPress, modifica tema, etc.), così da mantenere la cache sempre aggiornata.
Quali risultati sono stati raggiunti? L’infrastruttura progettata e messa a punto da ServerPlan assicura un’operatività continua con ridotti carichi computazionali su tutte le macchine di produzione, servendo il sito Web ad una velocità molto alta.
Attualmente la homepage del sito in oggetto ha un peso di 1,5 MByte (compresso tramite GZIP su Varnish) con circa 70 richieste per pagina (css/js/immagini) e viene caricata mediamente in 30 ms (prima risposta) per un totale (con tutte le risorse caricate) di 1,8 secondi.
Si tratta di un risultato di tutto rispetto, che sottolinea come una architettura ben congegnata consenta scalabilità, reattività e performance anche in caso di picchi di richieste.
