Noi di CrowdHandler incontriamo spesso persone che si trovano ad affrontare per la prima volta un picco di traffico. A volte, tutto ciò di cui hanno davvero bisogno è una sala d’attesa.
Tuttavia, spesso introducono per la prima volta anche server e sistemi di bilanciamento del carico – e sono desiderosi di discutere questi argomenti con noi.
Senza voler sembrare troppo sprezzanti, questa non è la preoccupazione principale del nostro prodotto. Per noi non ha molta importanza, poiché il nostro prodotto è indipendente dall’architettura che sta alla base della sala d’attesa. La nostra preoccupazione principale è la velocità con cui i nostri clienti riescono a elaborare le transazioni.
In effetti, è raramente fattibile aumentare la capacità al punto da poter gestire un traffico 10 volte superiore a quello abituale in occasione di picchi occasionali. Detto questo, più il sito è ottimizzato, più brevi saranno le code.
La maggior parte degli sviluppatori web ha una carriera più che dignitosa, pur senza aver mai lavorato a progetti davvero di successo. Di conseguenza, rimangono sorpresi nello scoprire che gran parte dei consigli sulle presunte “migliori pratiche” in circolazione non regge al confronto con la realtà.
La nostra esperienza deriva inizialmente dalla realizzazione di siti web ad alta disponibilità per grandi marchi del settore dei media e dell’intrattenimento. Abbiamo quindi una certa esperienza nel campo del ridimensionamento dei siti web. Sappiamo cosa funziona davvero e cosa no.
Ciò che non conta
Numero di server delle applicazioni
Potresti passare da un server condiviso a uno dedicato. O magari stai addirittura passando da un server dedicato a più server collegati a un bilanciatore di carico (sia presso un provider di hosting tradizionale che su un servizio cloud come AWS).
La verità è che capita raramente che i server delle applicazioni raggiungano il limite massimo di carico, quindi quel numero non è particolarmente significativo.
La gestione di attività in JavaScript, PHP o .NET finalizzate alla generazione di codice HTML o JSON non richiede un consumo eccessivo di risorse. Anche un solo server è in grado di gestire un volume di traffico piuttosto consistente.
Di solito si aumenta il numero dei server applicativi per garantire la ridondanza (in modo da poter gestire le richieste nel caso in cui un server smetta di funzionare). In contesti caratterizzati da un traffico elevato, i server applicativi tendono a trascorrere la maggior parte del tempo in attesa di qualcosa, spesso un database o un’API (che funge da database remoto).
Un server applicativo va in crash, in genere, quando esaurisce le connessioni in uscita mentre è in attesa di risposte a monte. Dieci server applicativi bloccati tutti in attesa della stessa query sul database o della stessa chiamata API non sono di grande aiuto.
Aggiunta di CPU al server del database (DB)
Quindi, questo significa che dovresti controllare prima il tuo server di database?
Spesso si sente usare il termine “cluster”, ma a meno che non si sia integrato lo sharding nella propria applicazione (date un’occhiata), non è possibile semplicemente aggiungere ulteriori server di database per scalare le prestazioni.
Certo, potresti passare a un server di database più potente con più core di CPU. Tuttavia, la maggior parte delle app moderne non grava in modo significativo sulla CPU del database. Le query che rallentano il sistema sono spesso limitate dalla velocità del disco (IO) — specialmente in ambienti cloud sofisticati in cui lo spazio di archiviazione del database si trova chissà dove, e si tende a sottovalutare la limitazione dell’IO finché non è davvero necessario affrontarla. A quel punto, ti rendi conto di quanto possano essere costose le prestazioni reali dell’IO.
Aggiunta dell'I/O del disco
Se analizzi i tempi di esecuzione delle query sul tuo server di database, scoprirai che aumentare le risorse della CPU e l’I/O del disco potrebbe essere d’aiuto, ma non abbastanza da impedire che il sito vada in crash sotto carico. Raddoppiare o addirittura quadruplicare le specifiche del database non salverà magicamente il tuo sito.
Perché no? Di solito, il motivo è che le query non sono ottimizzate a dovere — spesso sono generate da qualche framework molto diffuso ma poco efficiente — e non sono indicizzate correttamente. Applicando gli indici giusti, potresti vedere le query eseguire le operazioni 1.000 volte più velocemente. È una soluzione molto più conveniente rispetto a spendere 1.000 volte di più per il tuo server di database.
Scalabilità “infinita” del cloud
Sembra facile: basta cliccare su un pulsante per ottenere più esecuzioni/processi/criceti.
Ma anche se riesci a gestire alla perfezione tutte queste configurazioni e il costo ti sta bene, se ti affidi alle transazioni (come fa la maggior parte dei siti), incontrerai un collo di bottiglia proprio nella fase della transazione — sia che si tratti del tuo database (i database transazionali non possono scalare all’infinito; informati) sia che si tratti di un servizio di terze parti come un’API di pagamento (anch’esse sono basate su database transazionali con limiti di frequenza).
Ciò che conta
Metti in cache la pagina di destinazione
Hai presente quella pagina che tutti condivideranno su Instagram e simili?
Mettilo nella cache.
Non sprecare le risorse del server rigenerando la stessa pagina centinaia di migliaia (o milioni) di volte. Se si tratta di una pagina dinamica, rendila statica, o almeno parzialmente statica. Aggiungi un pulsante che rimandi a una fase separata di call-to-action nel caso in cui gli utenti debbano caricare l'inventario o altri dati dinamici.
Non sai quale sia la pagina più visitata dagli utenti? Scoprilo. Si tratta di un dato fondamentale. Configura le impostazioni della cache e utilizza un proxy inverso (come Varnish) o una CDN (come Cloudflare), oppure distribuisci un file completamente statico dal server web. Questa soluzione potrebbe non piacere agli sviluppatori, ma per i siti web che prevedono milioni di visite, la cache rappresenta l’80% del lavoro.
Utilizza una CDN (Content Delivery Network)
Un CDN è un sofisticato livello di cache distribuito. Sebbene ottimizzarlo appieno possa risultare complesso, iniziare a utilizzarlo è semplice. Pensi che i CDN servano solo a distribuire file statici in tutto il mondo?
Non proprio. Molti dei siti più trafficati di oggi utilizzano una CDN, indipendentemente da quanto possano sembrare “dinamici”. Infatti, questo principio è alla base di framework come Next.js/Vercel, che in questo modo raggiungono livelli di prestazioni notevoli. Ma non è una novità: le reti televisive, i siti di e-commerce e quelli di vendita dei biglietti utilizzano le CDN da prima che tu nascessi. I nuovi framework non fanno altro che semplificare l’approccio. Alcune opzioni di CDN includono:
- Cloudflare: conveniente, diffuso e semplice da configurare.
- CloudFront: è incluso in AWS, molto pratico se il tuo sito è ospitato su questa piattaforma.
- Akamai: uno dei pionieri del settore, utilizzato da molti grandi siti di e-commerce.
Utilizza una sala d'attesa
La maggior parte dei siti web presenta limiti transazionali che non è possibile superare tramite il ridimensionamento. Persino colossi come Ticketmaster ricorrono alle code durante i picchi di vendite, nonostante dispongano di un gran numero di server. Iniziate memorizzando nella cache ciò che è possibile memorizzare, quindi inserite una “sala d’attesa” a monte delle parti realmente dinamiche. È un primo passo migliore rispetto al ridimensionamento casuale dei server nella speranza di soddisfare la domanda.
Crea una sala d'attesa, imposta una velocità di transazione che sai di poter gestire e osserva il tuo sito durante i picchi di carico per individuare i colli di bottiglia reali, che spesso si trovano nel log delle query lente del database o nei tempi di risposta delle API. Potresti risolvere i problemi di scalabilità semplicemente aggiungendo un indice a una tabella. E imparerai dal comportamento effettivo del traffico, non da test di carico teorici o da supposizioni.
CrowdHandler
In contesti caratterizzati da un traffico intenso, la strategia più efficace non è un’espansione illimitata, bensì una gestione intelligente delle risorse. Le sale d’attesa sono fondamentali in questo senso.
CrowdHandler è specializzata nella fornitura di sale d'attesa virtuali flessibili e facili da integrare, pensate per aiutarti a gestire i periodi di maggiore affluenza.
Iscriviti oggi stesso per una prova gratuita.