“Perché il tuo sito web è andato in tilt? Dovevi pur sapere che ci sarebbe stato un gran traffico!”
È una frase che si sente spesso quando un sito web va in tilt in un momento cruciale. Sui social media vengono poste le stesse domande, sempre con lo stesso tono accusatorio. “Dovevano pur sapere che ci sarebbe stato un picco di traffico. Perché non hanno aggiunto qualche giga-qualcosa in più?”
Agli utenti delusi sembra ovvio che un’azienda avrebbe dovuto adottare maggiori misure preventive prima di un forte picco di traffico e che l’unica cosa che avrebbe potuto andare storta fosse una pianificazione inadeguata.
Ma quali sono queste misure preventive? Test di carico? Un “server più potente”? Magari più server? E che ne dite di uno di quei magici cloud serverless scalabili…?!
Spesso, la prima volta che incontriamo gli sviluppatori web di un team, li troviamo a una sessione di onboarding di CrowdHandler con la coda tra le gambe. Si sentono come se avessero fallito. Hanno fatto tutto secondo le regole eppure il sito web non è rimasto online; così ora, a causa dei limiti di tempo, sono costretti a rattopparlo alla bell’e meglio con una pagina di attesa. I primi dieci minuti della riunione servono proprio a chiarire le scuse.
Ne abbiamo sentite di tutti i colori. State ricostruendo la piattaforma e il nuovo sito non avrà questi problemi. Avete ereditato un codice legacy che non potete modificare. Siete bloccati su una vecchia versione del Framework X, nota per i suoi problemi di prestazioni. Potreste risolvere tutti i problemi, ovviamente; è solo una questione di tempistica.
Il motivo di questo imbarazzo è che la maggior parte dei colli di bottiglia – ovvero i problemi che impediscono ai siti web di gestire migliaia e migliaia di utenti – risiede nel codice, di cui gli sviluppatori si sentono responsabili.
Questi colli di bottiglia si trovano spesso nel backend: qualcosa che sta dietro al frontend – un sistema che gestisce, ad esempio, la vendita dei biglietti, gli appuntamenti o l’elaborazione delle carte di credito. Ma altrettanto spesso i colli di bottiglia si trovano proprio nel frontend stesso. Nel codice web. Codice su cui gli sviluppatori hanno il pieno controllo.
Ascoltare le scuse degli sviluppatori non ci fa sentire compiaciuti o superiori. Quello che proviamo soprattutto è un senso di riconoscimento. Ecco la verità: il codice di nessuno è scalabile fin da subito, e gran parte di ciò che vi è stato insegnato sulla scrittura di codice scalabile è sbagliato.
Tra un attimo ti spiegherò perché non è colpa tua, ma prima vorrei farti conoscere un nuovo modo di concepire la Sala d’Attesa.
Installare CrowdHandler non significa ammettere un fallimento. Anzi, potrebbe essere il primo passo verso la risoluzione del tuo problema di scalabilità. Piuttosto che considerarlo una soluzione temporanea, vorrei che pensassi a CrowdHandler come a uno strumento diagnostico che ti supporterà nel tuo lavoro e ti aiuterà a migliorare.
Non è colpa tua
Allora perché non è colpa degli sviluppatori se il sito web non riesce a gestire il traffico?
Il motivo per cui il codice tradizionale è pieno di colli di bottiglia legati al codice stesso è che gli sviluppatori web tradizionali non lavorano solitamente su siti web di grande popolarità. Quando gli sviluppatori web si formano e imparano, la loro comprensione dell’ottimizzazione e di come scrivere codice performante è – di solito – teorica.
Imparare a scrivere codice scalabile in teoria e poi vedere, nella pratica, centomila utenti accedere al tuo sito mi ricorda quella citazione di Mike Tyson: «Tutti hanno un piano finché non prendono un pugno in bocca». Ora hai preso un pugno in bocca. Dovresti esserne orgoglioso! La stragrande maggioranza degli sviluppatori web non lavora mai a progetti abbastanza popolari da scoprire come ci si sente.
Quindi, a te – e al tuo capo – vorrei dire: è del tutto normale che il vostro sito web non possa adattarsi magicamente per gestire qualsiasi livello di traffico. Non dovreste aspettarvelo.
Allora, qual è la risposta?
Ovviamente, vorrai rendere il tuo sito il più efficiente e scalabile possibile. Tuttavia, molte delle presunte soluzioni per la scalabilità, per il tipo di volumi di cui stiamo parlando qui, in realtà non funzioneranno.
Potresti concentrarti su framework e linguaggi che, in teoria, sono più veloci, ma nel quadro generale della situazione ciò fa poca differenza quando devi gestire migliaia o milioni di utenti.
Sai qual è la cosa che fa davvero la differenza? La cache. Non quel tipo di cache a oggetti precisa che si vorrebbe implementare vicino al server con Memcached, ma quella cache HTTP “dirty edge” vicina all’utente che sembra sfuggire al tuo controllo. Quella migliora davvero le prestazioni, ma è difficile da implementare correttamente ed è difficile da integrare a posteriori in framework e sistemi di gestione dei contenuti che non ne tengono adeguatamente conto.
Quindi immagino che potresti iniziare con i test di carico. Tuttavia, anche se questo può sembrare un po’ controverso, non credo che i test di carico di routine possano esserti di grande aiuto. Secondo la mia esperienza, spesso si tratta solo di una costosa perdita di tempo.
Perché? Perché il comportamento reale degli utenti è complesso. Potresti impostare percorsi utente di base per i tuoi test di carico che prevedono che gli utenti navigino su una pagina, selezionino un prodotto, lo aggiungano al carrello e procedano al checkout – ma non è ciò che accade nel mondo reale. Lì, i clienti vanno avanti e indietro, valutano tutte le opzioni, cambiano idea, si fermano a lungo prima di ricaricare le pagine, poi aprono quattro schede su prodotti diversi per confrontarli. Potrebbero esserci migliaia di questi percorsi complessi che si svolgono contemporaneamente, che fanno riferimento alle stesse righe del database in modi imprevedibili.
Potresti quindi eseguire una serie di test di carico sull’ambiente di staging che causano il malfunzionamento del sito web al raggiungimento dei due milioni di utenti e dichiarare che due milioni è il numero magico. Ma quanto sono realistici quei due milioni di percorsi utente? Dimostrano davvero due milioni di esperienze autentiche e fruibili nell’ambiente di produzione? Oppure il sito web live si sarebbe bloccato molto prima, quando gli utenti avessero iniziato a comportarsi in modo realistico? (Per non parlare del momento in cui qualcuno decide di generare un report di vendita intensivo proprio durante i saldi… oh, non state testando anche quello?)
Non dimentichiamo che i test di carico richiedono anche un’enorme quantità di tempo. Anche con uno script semplificato del percorso utente, dovrete ripetere i test più e più volte, risolvendo i problemi di configurazione finché non funzionano. E poi, una volta che funzionano, dovrete eseguirli fino a quando non mandano in crash il sito web. Può essere un ciclo senza fine. Molti dei nostri clienti semplicemente non riescono a far sì che i propri strumenti di test di carico generino la quantità di traffico che si aspettano di vedere nel mondo reale, oppure ritengono che farlo sia proibitivamente costoso.
Infine: la natura dei test di carico che stiamo descrivendo è quella di un progetto di ampio respiro. Conosco molte aziende che eseguono un test di carico su larga scala una volta all’anno. Tuttavia, immettono nuovo codice in produzione più volte alla settimana. È del tutto possibile che una sola riga di codice inserita nel posto sbagliato invalidi tutto lo sforzo profuso nel test di carico e modifichi completamente i numeri su cui state lavorando. Ora state implementando il codice in produzione utilizzando l’integrazione continua. Se solo ci fosse un modo per eseguire un test di carico continuo…
La prova di carico continuo
Vorrei che consideraste CrowdHandler come un’alternativa molto più produttiva e conveniente rispetto ai tradizionali test di carico. Perché? Perché CrowdHandler fornisce informazioni continue e realistiche sulle prestazioni, basate sul sito web che sta proteggendo, e vi permette di lavorare in modo più efficiente e iterativo.
Durante un periodo di vendita, la tua dashboard mostra il tempo di caricamento di ciascuna pagina e riassume le prestazioni complessive delle pagine. In tempo reale, la funzione di ottimizzazione automatica di CrowdHandler analizzerà la velocità delle pagine, monitorerà il numero di utenti e individuerà il numero ottimale di nuovi utenti che il tuo sito è in grado di gestire.
In altre parole, esegue un test di carico continuo sull’ambiente di produzione, utilizzando utenti reali e adeguando i risultati in tempo reale.
Ma – a differenza di un classico test di carico – dispone di una valvola di sicurezza integrata: la stessa sala d’attesa. Se i numeri dovessero rivelarsi completamente fuori dal normale, la cosa peggiore che potrebbe accadere non sarebbe il blocco del sito web, bensì una coda più lunga.
E poi, anche se gli utenti rimangono in coda un po’ più a lungo di quanto vorresti, puoi osservare e imparare dal comportamento del sistema in condizioni reali. Puoi individuare quali pagine sono particolarmente lente, il che ti permette di individuare i colli di bottiglia nella tua applicazione, mentre la funzione di ottimizzazione automatica gestisce la coda e garantisce un’esperienza utente positiva. Osservando i dati raccolti durante una vendita reale, puoi capire su quali parti del sito dovrai concentrarti per ottimizzarle la prossima volta.
In assenza di una “sala d’attesa”, se la vostra applicazione fosse affetta da un collo di bottiglia sconosciuto, sarebbe molto improbabile che riusciate a diagnosticarlo o anche solo a osservarlo, poiché il vostro sito web sarebbe inattivo e vi ritrovereste a cercare freneticamente di implementare misure di mitigazione d’emergenza. Anche se riusciste a recuperare i dati diagnostici in un secondo momento, un’emergenza causata da un carico in rapida escalation, aggravata da un traffico incontrollato, difficilmente vi consentirebbe di ottenere un quadro chiaro della causa principale.
Ed è per questo che considero CrowdHandler una parte essenziale del tuo kit di strumenti, piuttosto che un semplice rimedio di fortuna. Scegliendo la nostra "sala d'attesa", non stai gettando la spugna né ricorrendo a una soluzione affrettata: stai integrando uno strumento diagnostico aggiuntivo che può aiutarti a mantenere la lucidità mentale e ad apportare miglioramenti continui alle tue prestazioni, riducendo al contempo le critiche sui social media.
Quindi, se stai pensando di provare CrowdHandler, ti prego, non venire da noi con la coda tra le gambe. Tieni la testa alta! Sei uno sviluppatore web. Stai lavorando a progetti di grande successo e ti impegni a renderli ancora migliori. Stai facendo tutto nel modo giusto.