Uno strumento di monitoraggio esterno vi segnalerà che il tempo di risposta medio dei 5 URL monitorati è raddoppiato negli ultimi 30 minuti. Il progetto è in esecuzione su un singolo server fisico che non è sotto la vostra gestione ed è in esecuzione da qualche parte in un datacenter. Ci si collega via SSH, si avvia htop e si nota che il carico della CPU è del 95% e la memoria è da tempo sovrabbondante.
Secondo git, sapete che circa una settimana fa hanno fatto una migrazione del database a una nuova struttura di tabelle, e un collega scrive in chat che ha dovuto eseguire la migrazione durante la notte, perché il ricalcolo delle colonne e degli indici ha richiesto circa 5 ore, durante le quali quasi tutto il database era bloccato, e né INSERT né SELECT funzionavano.
Quindi i problemi di prestazioni sono probabilmente dovuti a indici progettati in modo improprio, a query SQL mal ridisegnate o a un grande pooling di connessioni. Non c'è tempo per un revert, ci sono 7 mila utenti sul sito secondo Google Analytics, e un'interruzione per 5 ore significherebbe un rischio reputazionale per il cliente, e una perdita di decine o centinaia di migliaia di corone in quel periodo (è difficile fare una stima, i proiezionisti ne fanno abbastanza). Ci si rende conto che testare solo la funzionalità in un ambiente di prova non è sufficiente e che è necessario implementare anche un test di carico.
Poiché si tratta di un importante negozio di e-commerce del vostro principale cliente e prevedete che la situazione possa peggiorare, avete 30 secondi per prendere una decisione.
Come si procede?
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu:
Články píše Jan Barášek © 2009-2024 | Kontakt | Mapa webu
Status | Aktualizováno: ... | it