Il traffico di un sito sportivo si concentra attorno a momenti riconoscibili: annuncio, convocazioni, partita e risultato. La preparazione tecnica deve considerare quei percorsi e la loro simultaneità, non soltanto la media giornaliera delle visite.
Con Romiltec lavoro anche sul web del Pisa Sporting Club, tra hosting, sviluppo e integrazioni. Un sito di club, un flusso per iscriversi a un campus e un’API di dati per broadcaster hanno requisiti differenti. Qui mi concentro sulla preparazione del servizio web durante un evento.
Individuare ciò che deve funzionare nel momento del picco
Partirei dalle azioni del lettore: aprire la notizia, leggere un aggiornamento, trovare informazioni pratiche o completare un’operazione. Ogni percorso può coinvolgere servizi esterni diversi dal sito principale.
Una homepage disponibile non dimostra che il modulo di iscrizione funzioni. Una pagina rapida non prova che il sistema di pagamento o un collegamento a un servizio esterno sia raggiungibile. La mappa del servizio deve includere questi passaggi.
Concorderei quali funzioni hanno precedenza e quale comportamento è accettabile durante un sovraccarico. Una componente accessoria può essere temporaneamente semplificata; un pagamento deve conservare correttezza e riconoscibilità dello stato.
Riprodurre la forma del traffico
Nel test includerei una crescita rapida delle richieste verso pochi contenuti, seguita da letture distribuite nell’archivio. Aggiungerei URL provenienti dai social con i relativi parametri: possono influire sulle chiavi di cache.
La prova deve usare un ambiente e un perimetro concordati. Colpire a pieno carico un pagamento reale o un’integrazione di terzi senza coordinarla produce effetti diversi da quelli che vogliamo misurare.
Osserverei errori, tempi dei percorsi, code e risorse durante il carico e nel recupero successivo. Una capacità che regge per pochi secondi non descrive necessariamente il comportamento di una finestra di partita.
Usare la cache dove la risposta è condivisibile
Articoli pubblici e media possono beneficiare di cache di pagina e CDN. Accessi personali, anteprime e operazioni con effetti richiedono regole differenti. Le direttive FastCGI di nginx permettono di distinguere lettura e salvataggio della cache; vanno configurate sul comportamento reale del sito.
Per un risultato o un aggiornamento live definirei quanto può essere vecchia la copia e come invalidarla. Anche un evento apparentemente definitivo può ricevere una correzione: la pipeline deve saper aggiornare il dato.
Nel pezzo sulla cache WordPress sotto carico descrivo un caso documentato in cui i parametri di tracciamento moltiplicavano i miss sulla stessa pagina. È un esempio di controllo da fare prima dell’evento.
Aggiungere capacità richiede di trovare il limite
Più worker applicativi aiutano se esiste capacità nei componenti successivi. Se tutti attendono lo stesso database o servizio remoto, aumentare i processi può soltanto aumentare la contesa.
Separerei letture, scritture e lavorazioni differibili quando il dominio lo consente. Le code possono assorbire variazioni temporanee, ma vanno osservati età dei messaggi, velocità di smaltimento e comportamento dei retry.
Il capitolo Google SRE sulla gestione del sovraccarico descrive anche risposte degradate e limitazione del lavoro. La scelta utile è preservare le funzioni essenziali prima che una dipendenza satura coinvolga tutto il servizio.
Preparare manutenzione e comunicazione
Prima di un appuntamento importante definirei una finestra in cui evitare modifiche non necessarie, un referente tecnico e una procedura per aggiornare le persone coinvolte. Serve anche un accesso alternativo se quello abituale dipende dal servizio in difficoltà.
Controllerei backup e recupero prima del picco, insieme alle scadenze dei certificati e alle quote dei servizi esterni. Un test di carico non sostituisce queste verifiche.
Dopo l’evento confronterei risultati e condizioni della prova: quali percorsi hanno rallentato, quali richieste sono fallite e quale margine rimaneva. Il resoconto deve riferirsi a quella finestra e a quei servizi, senza trasformare una partita riuscita in una garanzia generale di disponibilità.