Keliweb vs SiteGround vs Godaddy…

Versione Breve per i più pigri:

Per chi vuole solo una risposta e non è interessato a leggere tutta la mia analisi:

Nel corso della mia analisi, SiteGround e Godaddy come hosting condivisi wordpress si sono rivelati tra 10x e 20x più veloci rispetto Keliweb !!

Versione Dettagliata (ed estremamente tecnica):

Premetto che non sono mai stato un fan di WordPress, ma per forza di cose ho dovuto iniziare ad occuparmene, ed ho scritto questo articolo come risultato della mia esperienza diretta con Keliweb. che invito a contattarmi per qualsiasi rettifica…

Tutto è nato dal sistema di monitoring che uso (“MONITIS.COM”) per tenere sott’occhio altri miei siti: ho iniziato a ricevere allarmi in continuazione da uno solo in particolare, BURRACO.COM, che era proprio sull’hosting condiviso WORDPRESS, su IP dedicato, presso “Keliweb” – società che avevo scelto in quanto me ne avevano parlato bene.

Dopo una fase iniziale in cui non capivo dove fosse il problema, e dopo qualche scambio di messaggi con l’assistenza tecnica di Keliweb la cui soluzione puntava sempre a propormi di spostarmi su server “dedicato” (anziché a cercare di capire la natura del problema), ho deciso di approfondire la questione da solo, e di fare una piccola analisi per poi comparare le performance con altri due grossi competitor: SiteGround da una parte (trovato cercando su google) e Godaddy (che conosco e uso già da anni e su cui ho già un altro sito, sempre sotto WP su hosting condiviso).
La configurazione dalla quale inizio la mia analisi è quindi la seguente (ripeto un pò tutto): il sito è www.burraco.com , in hosting su KeliWeb su hosting condiviso, su IP dedicato. Davanti ci ho piazzato un CloudFlare che uso sia per sicurezza che per la parte HTTPS – e ovviamente non sto utilizzando il caching dei contenuti.

Gli strumenti che ho utilizzato per l’analisi sono: da una parte MONITIS.COM, che reputo il miglior monitoring system al momento, e che uso da qualcosa di più di 10 anni (quando ancora non si chiamava neanche così) e dall’altra parte semplicemente Google Chrome in modalità “debug”.
Monitis in particolare consente di effettuare il monitoring di una serie di servizi partendo da diverse datacenter sparsi per il mondo. Nel mio caso, quelli che scelgo solitamente sono Italia, Spagna, e US-EST perché mi consente di capire, quando c’è un problema, se è una questione limitata a problemi di connettività Europei o se la questione si estende anche oltre oceano. Ultimamente ho anche aggiunto la Francia per diversi motivi.

Per quanto riguarda Google Chrome in modalità “debug”, sono andato a verificare i tempi di caricamento delle pagine e cercando di capire dove esattamente si verificavano maggiormente i problemi. Nel dubbio, ho effettuato i test con Chrome da postazioni desktop dislocate in tre diverse location: Malta, Roma, e Firenze.
Per effettuare i test in maniera imparziale, ed escludendo CloudFlare, ho puntato un MONITIS in HTTPS direttamente sull’IP della macchina reale (185.17.107.119), su Keliweb, modificando a mano l’header in GET aggiungendo l’header “HOST” e facendolo puntare a www.burraco.com.

Successivamente, ho creato un secondo monitoring questa volta direttamente in HTTP, perché per una questione di validazione dei certificati SSL non è sempre possibile capire, in caso di monitoring, esattamente cosa stia succedendo, quindi ho puntato, in http, www.burraco.com, sempre con l’header modificato a www.burraco.com per evitare qualsiasi forma di redirect.

Ora passiamo ai grafici:

Questo sopra è il grafico a distanza di 1 settimana dalla data odierna, in HTTPS su IP diretto, con il sito ancora su Keliweb. Poiché i dati vengono collezionati ogni minuto, allontanando la vista al giorno e alla settimana (come in questo grafico) si ottengono delle medie. I punti rossi rappresentano i timeout, che fino al 17/6 sera erano impostati a 10 secondi (il default di monitis) mentre successivamente ho portato a 30 secondi per capire meglio cosa succedeva. Il tempo in secondi qui esprime il tempo necessario a scaricare fino agli header di risposta della pagina dal server http (almeno questa è la spiegazione fornita dal supporto tecnico di monitis). Monitis distingue infatti tra monitoring che fanno un successivo parsing dei contenuti della pagina (ad esempio, per verificare se una determinata stringa è presente nella pagina), e monitoring “puro” dove non interessa elaborare il contenuto della pagina, ma solo vedere se il sito è UP. Nel primo caso, ovviamente, loro dicono che il tempo si riferisce allo scaricamento di tutta la pagina html, senza ulteriori chiamate a immagini, css, o altro. Nel secondo caso, ovvero di solo monitoring senza verifica di contenuto, MONITIS dice che il tempo viene calcolato fino al ricevimento degli HEADER di risposta del server HTTP. Questo ovviamente include anche tutte le altre fasi, che sono più o meno la somma tra TCP_CONNECT + SSL_HANDSHAKE + http_REQUEST_SEND + http_REQUEST_RECEIVE + REDIRECTS. A me non ha convinto molto che in un caso il tempo si riferisca al raggiungimento degli HEADER di risposta del server http (anche perché gli HEADER non viaggiano mica su socket paralleli, ma viaggiano sullo stesso SOCKET su cui è stata fatta la richiesta, in testa alla pagina HTML, ma questa considerazione potrebbe non avere niente a che fare), ma nel dubbio e per spezzare una lancia in favore di Keliweb, facciamo finta che i tempi includono sempre anche il download intero della pagina html, non solo gli header, sempre senza eventuali immagini o css o altro.
Fatte tutte queste premesse, passiamo ad analizzare i risultati dei vari test.

Nel grafico pubblicato qui sopra, che si riferisce esclusivamente al sito hostato su Keliweb, si può notare come i tempi “medi” di attesa per la risposta della pagina, in HTTPS, sono attorno ai 6 secondi, con punte che spesso superano i 10 secondi purtroppo, e a volte superano anche i 30 secondi di attesa (vedere in particolare dopo il 17/ 6 , quando ho spostato il timeout da 10 a 30 secondi in cui si riesce a capire meglio l’andazzo).

Nel dubbio potesse essere un problema di qualche genere legato all’HTTPS, ho tirato su, come premesso, anche un monitoring in HTTP, diretto sempre sull’IP del server di KeliWeb, sempre modificando i request HEADER per includere come HOST www.burraco.com, e questo è il risultato:

Sembrerebbe andare meglio, ma siamo sempre in media intorno ai 3 secondi (come media giornaliera), e anche qui con svariate punte che superano i 10 secondi ed i 30 secondi (questa volta il monitoring l’ho settato direttamente con timeout a 30). Ma prendiamo in dettaglio un grafico, sempre dello stesso monitoring, limitato alle ultime 24 ore in modo da capire meglio cosa succede…

Questo è il risultato… in pratica ci sono sempre e comunque punte sopra ai 6 secondi, e spesso si superano facilmente i 30 secondi (i pallini rossi), per cui il grafico in quei singoli punti va in timeout. Quindi il poblema non è l’HTTPS, e in questo modo abbiamo fatto fuori qualsiasi dubbio inerente eventuali redirect dalla versione http a quella HTTPS. Inoltre il sito è comunque impostato per essere navigato su www.burraco.com e non su burraco.com, in questo modo non ci sono proprio redirect, sicuro al 100%, che possano rallentare il risultato.

In caso di ulteriori dubbi, ho fatto una verifica anche degli header inviati e ricevuti (non ho screenshot, mi dispiace), ma non ho rilevato anomalie neanche lì.
Il dubbio che mi è rimasto a questo punto è che si trattasse di problemi legati al routing (cioè sul fronte networking) – per questo motivo ho aggiunto un tracing MTR da un mio altro server Linux che uso per queste cose, il quale, tramite uno script bash “customizzato” mi fornisce un resoconto del routing dettagliato ogni minuto. Questo tool, MTR, che non è forse conosciuto ai più, si usa in ambiti professionali solitamente per capire se c’è stato un reinstradamento causato, ad esempio, da router danneggiati o dall’intervento di speciali meccanismi antiDDoS (i “vacuum” system che reinstradano il traffico a livello di routing BGP). Insomma, è una sorta di traceroute avanzato.

Nel grafico seguente ho oscurato volutamente, per ragioni di sicurezza, l’IP della mia macchina sorgente, il mio server Linux in Aruba. Il punto però è che anche durante i down, dai log ho verificato che il routing è rimasto inalterato (anche allargando la vista a diverse ore, per compensare eventuali differenze negli orari tra server diversi), e non ci sono perdite di pacchetti.

Durante tutti questi test, ho dovuto portare avanti (a volte un po’ a fatica) gli scambi di messaggi con il supporto di Keliweb, i quali hanno imputato il problema ogni volta a qualcosa di diverso. All’inizio ci hanno detto che il problema era che il monitoring puntava Cloudflare e che quindi il problema era probabilmente in CloudFlare, ma che in caso di problemi consigliavano… di passare a un dedicato. Quando abbiamo tolto Cloudflare dal monitoring e puntato l’IP diretto, ci hanno comunicato che il nostro sito spesso raggiungeva il 100% di CPU e quindi consigliavano… di passare a un dedicato. Quando abbiamo dimostrato che durante i down il consumo delle risorse del nostro server era sotto al 8% (grafici forniti dal loro stesso sistema), ci hanno detto che il problema era probabilmente nel nostro sistema di rilevazione, Monitis, consigliandoci… di passare a un dedicato. Lato mio c’è da dire che mi ero fissato sul fatto che il problema fosse il raggiungimento di un “timeout” lato loro (ovvero che le richieste venissero ad un certo punto “droppate”), mentre poi ho capito che avevo sbagliato di grosso, perchè quel “timeout” che vedevo proveniva dal raggiungimento della soglia tollerabile di risposta in secondi, impostata nel timeout di monitis. Però è anche vero, ed è una mia opinione, che un sito che impiega più di 10 secondi a rispondere dovrebbe comunque far scattare un campanello di allarme, soprattutto se la tua azienda si occupa principalmente di vendere proprio hosting condivisi… se il tempo impiegato non coincide con un consumo eccessivo, di quel cliente, delle risorse del server. Perchè altrimenti vuol dire che io sono costretto a passare ad un server dedicato perchè un altro cliente sta consumando troppe risorse. E’ un po come dover pagare una multa in spiaggia a te che non fumi perchè nel posto dove eri seduto altri hanno lasciato le cicche di sigarette.

E premetto comunque che, se il problema fosse stato che effettivamente il nostro sito occupava troppe risorse, non avrei avuto problemi a prendere un server dedicato. Ma il problema qui continuava ad essere la difficoltà nel riuscire a trovare una causa certa, ed io volevo trovarla.

Questi che seguono sono i grafici del consumo di risorse fornito dal pannello di Keliweb stesso, a circa 20 minuti da una serie di timeout uno dietro l’altro rilevati da MONITIS:

Quindi, escludendo problemi di routing e problemi di occupazione eccessiva (relativi alla nostra istanza) di CPU (tolto quello spike al 34% delle 16:10), come mai continuavo a ricevere problemi di caricamento così lunghi e continuativi ? Forse effettivamente il monitoring scarica comunque tutta la pagina html, e forse questa pagina ha un sacco di contenuti ? Oppure magari è un problema solo di MONITIS e di tutte e tre le webfarm in contemporanea (US-EST, Italia e Spagna) ? Per togliermi ogni dubbio sono andato a verificare con Google Chrome in modalità debug per vedere i contenuti e, nel dettaglio, i tempi di scaricamento direttamente dal mio PC (e più sotto anche da quelli di amici). Questi sono i risultati.

Da notare che per fare questo test ho modificato il file hosts della macchina per farlo puntare direttamente al mio IP dedicato in Keliweb, per evitare eventuali redirect e/o problemi legati a CloudFlare ed ho puntato direttamente http:// anziché https://. Il “DOMContentLoad” mi da ben 3,90 secondi (immagino sia 90 centesimi di 60 secondi, ovvero quasi 4 secondi), il che sembra abbastanza in linea con la media di caricamento rilevato da Monitis dalla Spagna, dall’Italia e da US-EST. Ma come mai ci impiega così tanto ? Considerando che comunque il DOMContentLoad prevede anche la fase di “conversione” del testo nella costruzione del vero DOM, inteso come object model, bisogna dire che su questo processo incidono anche la CPU/le prestazioni del PC. Ma la mia è una macchina da developer, 1 CPU da 8core intel I7 con 32GB di Ram, su dischi SSD, e soprattutto scarichissima come carico di risorse, quindi se azzardo a dire che l’elaborazione di un processo del genere potrebbe prendere 0,001 secondi (ovvero 1 millisecondo), forse sto anche esagerando (in pessimismo).

Quindi… andiamo avanti … da una rapida analisi (e qui non ho approfondito, ci sarebbe in realtà ancora tanto lavoro da fare, partendo da qui) vedo che c’è un TTFB abbastanza alto, che è di 1.87 secondi. E’ in pratica il tempo che impiega il server http a fornire il primo byte di risposta. Dallo screenshot si vede che anche per la custom.css ci sono voluti 1.86 secondi di TTFB. Sembrerebbe quindi un problema legato al sovraccarico dei server, che potrebbe non essere in grado di soddisfare le richieste in tempi più brevi perchè occupato in altre risorse ? Finalmente è la prima risposta sensata e verificata che inizio ad accettare…

Ad ogni modo, il “content download” ha un valore più che accettabile: 0,34 ms. Quindi da una parte la pagina html non occupa eccessivo spazio, e dall’altra la connettività intesa come velocità/ampiezza di banda si conferma essere a posto. Tutto sembrerebbe confermare quindi la teoria di un semplice problema di sovraccarico/configurazione del server, e magari solo di quello dove sono finito io.

Rimane ancora un dubbio… potrebbe essere, oltre ad un problema verificato da tre diverse location di Monitis, anche un problema mio di connettività/lentezza di scaricamento ad internet ? Premesso che ho una 100Mbit in fibra, ma sono a Malta, nel dubbio ho effettuato gli stessi test dal PC “casalingo” di un amico che è a Roma e che usa Telecom Fibra come connessione a internet… e i risultati sono sempre gli stessi, se non in alcuni casi anche peggiori:

Dallo screenshot qui sopra fatto da casa del mio amico a Roma si vede chiaramente un TTFB da 3,43 secondi … e un DOMCONtentLoaded da 10,34 secondi… il che conferma una volta ancora che i dati sia di MONITIS che del mio PC sembrerebbero essere tutti corretti.

Ok, a questo punto mi sono detto… “forse questi sono i dati normali di tutte le aziende che fanno hosting condiviso”… nel dubbio, andiamo a verificare cosa succede su un altro mio sito wordpress ospitato questa volta su Godaddy:

Il grafico mi sembra molto, molto lineare… non ha tutti quegli isterismi che ha KeliWeb, e dall’italia abbiamo adirittura 36ms come tempi di risposta. Lo spike massimo c’è stato alle 23:35 dove una unica richiesta, dall’Italia, ha impiegato 209 ms. Una bella differenza contro i circa 7 secondi di burraco.com che ho su Keliweb !! ovvero circa il 97% di tempo in meno. OK, però si tratta di un sito diverso, sicuramente ci saranno altri fattori che potrebbero influenzare il risultato … quindi per fare il test finale … ho preso un hosting con SiteGround, ho trasferito tutti i file di burraco.com di wordpress, ho traferito il database, ed ho aggiornato i DNS per farli puntare al nuovo IP, senza cambiare NULLA nei sistemi di monitoring. Solo l’IP.

Questo è il risultato:

I tempi di risposta sono passati da punte di 7.692 ms a 147 ms … in altre parole, ho acquistato una velocità di 52X …

E vediamo ora cosa succede ai grafici in HTTPS che passano attraverso CloudFlare…

Si passa da 14.117 ms (ovvero 14 secondi) a 505 ms (ovvero mezzo secondo!)… in altre parole, ho acquistato una velocità di 28X superiore… come minimo.

Però non bisogna cantare vittoria troppo presto … c’è da dire che potrebbe esserci un problema legato ai tempi di propagazione dei DNS per il cambio dell’IP dell’host, e quindi monitis potrebbe stare monitorando un sito a cui arrivano solo una parte delle richieste (perchè le altre continuerebbero ad arrivare al vecchio server)… ma è anche vero che circa una settimana prima di tutta questa analisi avevo già abbassato i TTL dei singoli record DNS a pochi minuti (in previsione…), ma è altrettanto vero che tanti provider se ne fregano delle RFC sui DNS (uno tra tutti, fastweb) e quindi ho preferito aspettare ancora diverse ore affinchè si aggiornassero anche i DNS più ritardatari, e questi sono i risultati:

Per le richieste in HTTP, in pratica sono passato da una media di 4.294 ms con punte sui 6.000 / 7.000 ms (ovvero 7 secondi), a una media di 485 ms con punte molto meno ricorrenti attorno a 1.063 ms… diciamo che il guadagno in termini di rapporto è comunque 10X circa, e in più esteticamente ho un grafico molto più coerente, lineare e meno isterico… segno ulteriore che le mie performance venivano impattate probabilmente da qualche altro cliente.
Diamo un’occhiata anche alla differenza in HTTPS:

Siamo passati da una media di 4.480 ms, con punte spesso sui 15.000 ms (senza considerare quell’unico spike oltre i 20 secondi) a una media di 546ms con punte di circa 1 secondo. Anche qui il guadagno medio è di 10X ma se consideriamo la frequenza degli spike oltre i 10 secondi, il guadagno in questo caso è di circa 20X…

Dopo tutte queste analisi e considerazioni, i punti chiave che ho tratto, in base all’esperienza fatta è stata che:

1) Keliweb potrebbe risultare molto lenta, quando utilizzata come hosting condiviso, e quando succede è poco interessata a trovare le cause di eventuali rallentamenti di un singolo sito web, puntando sempre a offrire come soluzione un hosting dedicato. Il che non è sbagliato dal punto di vista commerciale, se la colpa è effettivamente del cliente che consuma troppe risorse, ma diventa una vera ingiustizia qualora la colpa sia… di qualcun’altro ed io sia costretto a passare all’hosting dedicato per questo motivo ! Anche se il supporto risponde in tempi veloci, se il vostro problema sono le performance, ce ne sono altri da prendere in considerazione come SiteGround (oggetto principale di questa analisi) ma anche Godaddy.

2) SiteGround e Godaddy sono entrambi validissime alternative, che nei miei test non hanno avuto i problemi che invece ho avuto in Keliweb.

Invito Keliweb, qualora interessata, a contattarmi o a rispondere qui qualora io abbia omesso qualche particolare o non abbia considerato qualcosa di importante (che può sempre succedere)!

Ringrazio tutti quanti hanno avuto la pazienza di leggere l’articolo fino a qui e… aspetto commenti !