Ett externt övervakningsverktyg rapporterar att den genomsnittliga svarstiden för de fem övervakade webbadresserna har fördubblats under de senaste 30 minuterna. Projektet körs på en enda fysisk server som du inte har hand om och som körs någonstans i ett datacenter. Du ansluter via SSH, startar htop och ser att CPU-belastningen är 95 % och att minnet är överfullt.
Enligt git vet du att de för ungefär en vecka sedan gjorde en databasmigrering till en ny tabellstruktur, och en kollega skriver i chatten att han var tvungen att köra migreringen över natten, eftersom omräkningen av kolumner och index tog ungefär 5 timmar, under vilka nästan hela databasen var låst och varken INSERT eller SELECT fungerade.
Så prestandaproblemen beror troligen på felaktigt utformade index, dåligt utformade SQL-förfrågningar eller stor anslutningspooling. Det finns ingen tid för en återgång, det finns 7 000 användare på webbplatsen enligt Google Analytics, och ett avbrott i fem timmar skulle innebära en risk för kundens rykte och en förlust av tiotals till hundratusentals kronor under den tiden (det är svårt att uppskatta, projektionisterna hittar på tillräckligt mycket). Du inser att det inte räcker med att bara testa funktionalitet i en testmiljö, utan du måste också genomföra ett belastningstest.
Eftersom detta är en viktig e-handelsbutik för din största kund och du räknar med att situationen kan förvärras har du 30 sekunder på dig att fatta ett beslut.
Hur går du vidare?
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-2025 | Kontakt | Mapa webu
Status | Aktualizováno: ... | sv