Vogliamo documentare con questo articolo la vicenda di un “abbastanza noto” venditore di pannolini ecologici online che genera circa 20 mila visitatori unici al mese e circa 300 mila pagine viste al mese.
Il traffico insomma dal punto di vista prettamente sistemistico non è in alcun modo elevato, sebbene più che adeguato a livello imprenditoriale per generare importanti profitti.
Tuttavia il vecchio hoster aveva importanti problemi di performance di navigazione che in alcuni casi rendeva assolutamente innavigabile il sito web con relativi errori di timeout e bad gateway.
Un 502 Bad Gateway su Magento sta a significare che si è raggiunto un timeout per l’attesa di una risposta HTML dall’interprete PHP che gira dietro il webserver NGINX.
Il perchè può avere molteplici motivi, ma essenzialmente il motivo principale è che PHP non riesce a completare l’esecuzione del suo codice e restituire un output al Webserver.
Il problema è nella lentezza del codice ? Il problema è nella lentezza della macchina ? Un sottodimensionamento dell’hardware ? Un overselling delle risorse ?
Essenzialmente possono essere vere tutte le motivazioni, ma di sicuro ciò che interessa ad un imprenditore non è tanto capire a cosa sia imputabile la causa ma che il sito web sia online e generi vendite, dunque utili, dunque profitti.
Collegandoci al pannello di controllo cPanel del vecchio Hoster, la prima cosa che notiamo è l’elevato picco di consumo CPU, che arriva quasi al 200% del massimo carico concesso.
Nello specifico controllando la colonnina completa qui sotto vediamo che questo valore è un valore praticamente superato in maniera eccessiva da giorni, e che dunque il problema non è dovuto ad uno spike (un picco) di visite, a qualche scansione, a qualche bot o crawler malizioso, ma semplicemente uno standard assolutamente inadeguato che compromette la normale navigazione di potenziali clienti e sicuramente anche il crawling dei contenuti da parte di motori di ricerca come Google, penalizzando dunque anche a livello SEO.
Nello specifico possiamo leggere che nelle ultime 24 ore, il tempo di utilizzo della CPU è di circa 60000 contro i 20000 consentiti, ovvero esattamente il triplo.
Ma cosa starà eseguendo un ecommerce Magento del genere per risultare così lento e così avaro di risorse come la CPU ?
Verrebbe da porgersi diverse domande in merito ma “tirando ad indovinare” e tenendo in considerazione casi precedenti molto simili con lo stesso fornitore abbiamo pensato fosse opportuno variare hosting e migrare il tutto sui nostri sistemi.
Abbiamo pertanto optato ad una configurazione su un server Entry Level corredato di Linux CentOS 7, che possa assicurare oltre che una pronta risoluzione del problema di carico, anche una velocità di esecuzione ottimale, un triplo backup, un sistema di monitoring delle risorse come ZABBIX e una protezione DDOS Layer 3 e Layer 7.
La migrazione è avvenuta in varie fasi completate con la messa offline del sito principale e il puntamento dei DNS verso la nuova configurazione, con un down percepito effettivo di circa 5 minuti per accertarsi che l’ecommerce non andasse in split mode e dunque registrasse pagamenti e ordini sia sul vecchio che sul nuovo hosting.
Il server è stato corredato di Kernel 5.0 e TCP BBR per ottenere migliorie a livello di rete anche per connessioni smartphone 3G non ottimali, un adeguato tuning MySQL, http/2 e vari virtuosismi tecnici che rientrano nella nostra “ricetta segreta”.
Consumo della CPU dopo la migrazione sui nostri sistemi.
Nel post migrazione del sito sui nostri sistemi abbiamo deciso di valutare il carico della CPU per capire effettivamente se ci fosse un miglioramento del tutto ed eventualmente intervenire (qualora non fosse bastato) ad una profilazione con New Relic APM per capire nel dettaglio cosa non andasse a livello applicativo.
Come invece ipotizzato in fase iniziale, il problema non era applicativo ma bensì a livello di configurazione e dimensionamento dell’hardware.
Il carico della CPU nel primo giorno di hosting presso i nostri sistemi infatti non ha mai superato il 10% nemmeno a fronte di operazioni schedulate come Backup di Database e file fisici.
Qui sotto potete vedere il carico delle ultime 24 ore, o meglio dalle 2:30 in cui è stato installato l’agente Zabbix ad ora che l’articolo è stato scritto.
Sebbene non sia molto chiaro per chi non è abituato a leggere dei grafici ZABBIX, l’area verde rappresenta il tempo di CPU in idle time, ovvero non occupata e la linea blu (difficile anche da vedere ad occhio nudo) il consumo della CPU che secondo la legenda ha un valore medio dello 0,85% e un massimo valore del 6%.
Come mai nell’altro hosting il consumo della CPU era di 60000 su 20000 ovvero un consumo standard effettivo del 300% ?
Ancora una volta, non sta a noi rispondere a queste domande, ma solo dimostrare che la soluzione a problemi di carico esistono e noi siamo abitualmente una delle soluzioni più gettonate da imprenditori, SEO e sviluppatori che decidono di fare business proficui online e non solo tenere online un sito lento e snervante che non porta alcun profitto.
Disporre di un Hosting Magento Performante significa offrire al cliente la possibilità di massimizzare i profitti. Non esistono spese, ma solo investimenti.
