Externí monitorovací nástroj vám zahlásí, že se průměrná doba response z 5 sledovaných URL zvýšila na dvojnásobek za posledních 30 minut. Projekt běží na jednom fyzickém serveru, který není ve vaší správě, a běží kdesi v datacentru. Připojíte se přes SSH, spustíte htop, a vidíte, že zátěž CPU je 95 % a paměti jsou dávno přeplněné.
Podle gitu víte, že se asi týden zpět dělala migrace databáze na novou strukturu tabulek, a kolega do chatu píše, že musel migraci spustit přes noc, neboť přepočet sloupců a indexů trval asi 5 hodin, během kterých byla skoro celá databáze zamknutá, a nefungoval INSERT ani SELECT.
Za problémy s výkonem tedy pravděpodobně mohou nevhodně navržené indexy, špatně předělané SQL dotazy, nebo velký connection pooling. Na revert není čas, na webu je podle Google Analytics právě 7 tisíc uživatelů, a výpadek na 5 hodin by znamenal reputační riziko u klienta, a za tu dobu ztrátu desítek až stovek tisíc korun (těžko odhadnout, projeťáci si toho vymyslí dost). Uvědomíte si, že testovat pouze funkčnost na testovacím prostředí nestačí, a musíte zavést i test zátěže.
Protože jde o důležitý e-shop vašeho největšího klienta, a očekáváte, že se situace může zhoršit, na rozhodnutí máte 30 sekund.
Jak se zachováte?
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:
Nabízím trénink vývojářů, konzultace, školení a analýzu návrhových vzorů. Osobně v Praze nebo online.
Napište mi, pokud si nevíte rady.
Lektor: Jan Barášek
Články píše Jan Barášek © 2009-2024 | Kontakt | Mapa webu
Status | Aktualizováno: ... | cs