Indice dei contenuti dell'articolo:
Qualche settimana fa abbiamo parlato di come nel mese di ottobre il sito Birredamanicomio.com sia andato offline durante un passaggio promozionale in uno spot in TV su X Factor. Abbiamo fatto un’analisi piuttosto chiara ed oggettiva delle mancanze e delle carenze che hanno portato al down di quel sito ospitato non da noi ma da un altro fornitore hosting, spiegando come la mancanza di una cache statica fosse stata determinante al crash che abbiamo voluto anche documentare con una registrazione video dello smartphone sempre a questo articolo intitolato per l’appunto Come non andare in TV col tuo sito WooCommerce se non opportunamente configurato lato Server ed Hosting.
Nemmeno a farlo apposta, tempo nemmeno un mese abbiamo modo di mostrare con dei fatti tutta la teoria che abbiamo dispensato tramite belle parole nel precedente articolo che denotava il downtime ed il crash del server di un nostro competitor e concorrente.
Il caso specifico: X-Bio su RAI1 a l’eredità con Flavio Insinna.
X-Bio è il marchio di un nostro cliente (Il Gruppo Buoninfante Medical) che produce Materassi di elevata qualità e caratura che ha provveduto ad un lancio di portata nazionale quello riservato a X-BIO Circulife, nuovo modello della linea X-BIO by Buoninfante – brand dell’azienda produttrice di materassi nata nel 1975. Da lunedì 7 a venerdì 11 novembre X-BIO Circulife sarà in TelePromozione su RAI 1 durante L’Eredità, programma condotto da Flavio Insinna dalle ore 18.45 alle ore 20.00.
Innovativo sotto ogni aspetto, dal design unico e capace di tutelare salute e ambiente, X-BIO Circulife è il primo materasso della linea prodotto a partire da bottiglie di plastica riciclate. Un prodotto nuovo che guarda ad un mondo più sostenibile, al benessere della persona e al futuro del Pianeta e delle prossime generazioni.
A tal proposito, dunque, con uno spot che rimandava esplicitamente al sito web, X-bio.it non c’era possibilità alcuna se non quella di provvedere ad ottimizzare server e stack software al fine di reggere il picco di traffico in un programma sul primo canale nazionale e visto da milioni di persone.
Preoccupazioni e preparazioni lato server ed Hosting a meno di due ore dal lancio.
Va detto per correttezza che non abbiamo avuto molto tempo per preparare il tutto, anzi la cosa è stata piuttosto improvvisata dato che non eravamo stati avvisati con largo anticipo ma appena due ore prima della messa in onda del 7 Novembre.
Quando ci siamo sentiti con lo sviluppatore che era preoccupato per la velocità del sito e dell’imminente messa in onda a meno di due ore, il primo commento da parte nostra è stata un’affermazione di questo tenore pressappoco:
Andrete offline, inevitabilmente. Senza se e senza ma. Per queste evenienze ci si prepara almeno con una settimana di anticipo.
Tuttavia, la cosa lasciata così suonava male. Molto male, più per noi che per loro. Non potevamo lasciare che il sito andasse offline nel mezzo di quell’evento, e non era nemmeno bello, dopo che abbiamo documentato il mese prima un articolo intitolato Come non andare in TV col tuo sito WooCommerce se non opportunamente configurato lato Server ed Hosting.
Va bene che in questo caso il sito era un e-Commerce realizzato in Prestashop e non WooCommerce, ma la cosa non cambiava poi molto.
Avevamo a diposizione due ore. Poche, molto poche, ma non pochissime.
Qualsiasi cosa avremmo fatto sarebbe stata fatta in maniera certa e molto ma molto veloce.
Andava tenuto conto ovviamente del dato Auditel, dato che l’Eredità, ha raccolto uno degli share più alti dell’intero lunedì con ben 4.39 milioni di spettatori e uno share del 25.4%.
Cosa avremmo potuto fare, considerando che l’Hosting Prestashop ed il sito girava già su un server dedicato AMD Ryzen 3600 con 6core / 12 thread – 64 GB RAM e due dischi nVME in RAID1 e un uplink da 1Gbit/s ?
Sicuramente non avremmo avuto il tempo necessario per ordinare una macchina con più core e thread, non avremmo avuto più tempo per ordinare un uplink da 10Gbit/s e una scheda di rete da 10Gbit, anche perchè la macchina andava ordinata, installata, configurata, migrata, 4 ore nella migliore delle ipotesi, non due.
Pertanto, ci siamo “limitati” a switchare in fretta e furia i nameserver da Godaddy a CloudFlare che ci avrebbe consentito di assorbire il picco di traffico per le immagini multimediali, jpeg, png, css e js, nonchè configurare il server con una configurazione avanzata che includesse una Full Page Cache lato server come Varnish.
Perchè sebbene sia credenza comune che CloudFlare faccia Cache dell’html è bene ricordare che CloudFlare non fa cache l’HTML di default, a meno che non si vada su costosi piani a pagamento e si faccia una configurazione a puntino limitata ed ostica rispetto a quanto si possa fare elegantemente in pochi minuti e gratuitamente con Varnish
Il sito ha retto egregiamente senza down e senza rallentamenti con estremo stupore, soprattutto il nostro. Purtroppo, data l’impellenza ed i tempi strettissimi, non abbiamo avuto modo di documentare come avremmo voluto l’evento, tuttavia, ci siamo promessi che ci sarebbe rifatti con una migliore reportistica e documentazione nel passaggio televisivo nel giorno seguente.
Prepararsi meglio per la durata della televendita dell’intera settimana dal 7 all’11 Novembre.
Consapevoli che il lancio sarebbe durato ulteriormente altri 4 giorni, abbiamo voluto migliorare ulteriormente l’infrastruttura utilizzando in primis un Hardware decisamente più potente. Siamo passati infatti dai 6core / 12 thread a 16core / 32 thread, triplicando di fatto il numero di thread disponibili, sicuramente utili e potenzialmente determinanti per lo spawn di processi PHP-FPM e per i thread di Percona Server (un fork di MySQL).
In tutto ciò abbiamo ovviamente rivisto il tuning del webserver, del DBMS, di PHP-FPM, al fine di trovare il migliore compromesso tra velocità e multithreading, evitando carichi eccessivi ed eventuali deadlock a livello DB.
Il tutto è stato fatto con un approccio commerciale anche piuttosto interessante, ovvero quello di noleggiare la macchina per il tempo previsto gratuitamente. Non possiamo addentrarci nel dettaglio dell’argomento, ma basti sapere che per situazioni del genere, possiamo ad esempio noleggiare una macchina da 500 euro / mese in modo completamente gratuito senza caricare un solo centesimo al cliente finale, se non il costo di setup / migrazione e consulenza sistemistica.
Non solo Stack Server, anche implementazioni applicative su Prestashop.
Sebbene la parte server fosse stata di estrema facilità di implementazione, la parte software applicativa invece avrebbe avuto di una necessaria modifica lato applicativo da parte dello sviluppatore. Perché se è vero che dati alla mano, Prestashop risulti essere un CMS orientato all’ecommerce migliore sotto moltissimi aspetti, tra cui le performance, rispetto a WooCommerce, è a anche vero che Prestashop non si presta bene a lavorare con tecnologie di scaling e di caching come Varnish.
Si può utilizzare Varnish di default, ma poi si rischia che l’utente non possa loggarsi o portare a termine un acquisto, il che non ha alcun senso dal punto di vista prettamente imprenditoriale.
Abbiamo dovuto pertanto far inserire una routine in fase di login che creasse un cookie per contraddistinguere un utente loggato e metterlo nella condizione di navigare la sua area cliente, con i suoi dati e senza rischiare di essere sloggato.
Sebbene sia relativamente facile far funzionare Prestashop con Varnish, non lo è altrettanto farlo funzionare BENE.
Come è andato il nuovo server? Giudicate voi stessi.
Potremmo dare numeri, parlare di carichi, velocità delle query, Hit ratio della Cache e tante altre cosette. Quello che però preme soprattutto al visitatore finale, è quello di trovare un sito disponibile, veloce e scattante nel momento in cui Flavio Insinna nomina il nome del sito e non un errore 500 per esaurimento delle risorse, un Bad Gateway, o un sito che carica la prima pagina in 16 (sedici) secondi, come abbiamo avuto modo di misurare e documentare sul caso prima menzionato “Come non andare in TV”.
Pertanto, oltre a dire che il server ha retto egregiamente, lavorando sempre abbondantemente entro la zona confort (per noi la zona confort è al 50% del numero di thread), ovvero a fronte di 32 thread, laddove un load average di 32 corrisponde al 100%, la zona conforte la consideriamo entro 16 di load Average.
Abbiamo utilizzato Camtasia Studio per registrare tutto l’evento in “presa diretta”, guardando la diretta su Ray Play e poi in contemporanea andare a visionare cosa stava succedendo sul terminale a livello di carico, e sul browser Microsoft Edge per simulare la navigazione di un normalissimo utente appena terminato lo spot.
Potete visionare il video e l’analisi del video con schermate server, carico, pool, e test di velocità del sito e del TTFB direttamente in questo video, creato allo scopo di documentare come si possa andare anche in TV senza per questo avere crash o downtime o dover spendere cifre folli in dubbie tecnologie come Cloud, cluster o affini. Ricordando sempre che ogni caso è comunque un caso a se, e non necessariamente questa soluzione per questo caso, sia adatto a tutte le necessità di siti ad alto traffico.
