Audit výkonu aplikace a databáze

Pomalá aplikace nemusí mít jedinou jednoduchou příčinu

Stejný projev může mít několik zdrojů. Obrazovka může čekat na databázi, externí API nebo frontu. Příčinou může být také příliš mnoho operací, chybějící či nevhodně použitá cache, způsob zpracování dat, konfigurace prostředí nebo práce v prohlížeči.

Proto audit nezačínáme náhodným přidáváním indexů ani změnou serveru. Nejdříve určíme, který scénář je pro firmu důležitý, za jakých podmínek problém vzniká a jak ho lze opakovaně změřit. Teprve potom prověřujeme jednotlivé části systému.

Kdy má takový audit smysl

Důležitá činnost trvá stále déle

Může jít o otevření reportu, uložení objednávky, vyhledávání, import dat, vytvoření dokumentu nebo operaci, kterou zaměstnanec provádí mnohokrát denně.

Systém zpomaluje spolu s růstem firmy

Větší množství dat, uživatelů nebo integrací odhalilo omezení, které dříve nebylo vidět. Potřebujete zjistit, zda je problém v dotazech, kódu, architektuře nebo prostředí.

Objevují se timeouty a kolísavé doby odezvy

Stejná činnost jednou proběhne rychle a jindy celý proces zastaví. Často se to týká front, pravidelných úloh, integrací, importů a současně prováděných operací.

Máte několik hypotéz, ale chybí důkazy

Někdo navrhuje výkonnější server, jiný přestavbu databáze a další změnu frameworku. Audit má oddělit příčinu od projevu a seřadit práce ve správném pořadí.

Nejdříve určíme, co v daném systému znamená „pomalu“

Neexistuje jedno číslo, které by popsalo výkon celé aplikace. Načtení veřejné stránky, uložení rozsáhlého formuláře, výpočet reportu, zpracování fronty a import tisíců záznamů vyžadují odlišná měření.

Před měřením si odsouhlasíme:

• konkrétní obrazovku, činnost nebo proces;
• prostředí a podmínky, za kterých problém vzniká;
• objem dat, počet operací nebo zatížení potřebné k jeho zopakování;
• dostupná měření, technické logy a omezení přístupu;
• způsob, kterým se ověří přínos budoucí opravy.

Díky tomu porovnáváme stejné podmínky a neděláme závěry z jediného náhodného testu.

Příklad: pomalý report automaticky neznamená chybějící index

Představme si, že se report prodeje otevírá několik sekund. Příčinou může být jeden náročný dotaz, ale také stovky drobných dotazů ve smyčce, čekání na externí službu, zpracování příliš velkého množství dat v aplikaci nebo generování odpovědi, kterou uživatel nepotřebuje celou.

Přidání indexu bez kontroly plánu provedení nemusí nic změnit. Navýšení parametrů serveru může problém pouze odsunout. Proto nejdříve situaci zopakujeme, shromáždíme měření a zjistíme, kde se čas skutečně spotřebovává.

Jde o hypotetický příklad způsobu analýzy, nikoli o popis konkrétního projektu nebo příslib, že každá aplikace má stejný problém.

Co můžeme prověřit

Přesný rozsah dohodneme před zahájením. Ne každá aplikace vyžaduje všechny následující oblasti.

Provádíme pouze měření bezpečná pro dohodnuté prostředí. Činnosti, které mohou měnit data, zvýšit zatížení nebo ovlivnit uživatele, vyžadují samostatné rozhodnutí a odpovídající testovací podmínky.

Jak audit probíhá

1. Krátce ověříme vhodnost zakázky

Rozhovor do 20 minut nám pomůže pochopit projev problému, jeho dopad na firmu a potřebné přístupy. Je zdarma, ale nenahrazuje diagnostiku, analýzu kódu ani zprávu.

2. Dohodneme rozsah a bezpečné podmínky

Určíme zkoumané scénáře, prostředí, podklady, omezení a formát výsledku. Pokud je potřeba zátěžový test, domluvíme také jeho rozsah a způsob ochrany fungujícího systému.

3. Zopakujeme problém a zaznamenáme výchozí stav

Shromáždíme měření pro dohodnuté činnosti. Pokud se problém nepodaří zopakovat, popíšeme toto omezení, místo abychom důkazy přizpůsobovali pohodlné hypotéze.

4. Oddělíme jednotlivá úzká místa

Prověřujeme pouze vrstvy zahrnuté v dohodnutém rozsahu. Porovnáváme měření, plány provedení a chování aplikace, abychom určili příčiny podložené důkazy.

5. Stanovíme priority a způsob ověření

Oddělíme rychlé opravy od změn vyžadujících rozsáhlejší modernizaci. U každého důležitého doporučení popíšeme, jak po zavedení ověřit jeho přínos.

Co získáte

Rozsah výstupu určíme v nabídce. Obvykle zahrnuje:

• popis zkoumaného rozsahu a podmínek měření;
• výchozí stav založený na provedených měřeních;
• potvrzená úzká místa s důkazy a prioritou;
• krátkodobá doporučení a změny vyžadující další vývoj;
• způsob opakovaného ověření po zavedení oprav;
• navržené pořadí prací;
• samostatný odhad implementace, pokud lze rozsah spolehlivě určit.

Shrnutí předáme ve formátu dohodnutém před zahájením. Můžete ho použít při další spolupráci s Domin Software nebo ho předat jinému dodavateli při zachování důvěrnosti a bez veřejného sdílení materiálů.

Proč samotné skóre Lighthouse nestačí

Lighthouse pomáhá zkoumat načítání konkrétní stránky v laboratorních podmínkách. Samostatně ale nepopisuje databázi, fronty, importy, části dostupné po přihlášení ani skutečné chování všech uživatelů.

Google rozlišuje laboratorní data a data od skutečných uživatelů. Výsledky se mohou lišit podle zařízení, sítě, lokality a podmínek testu. Pokud audit zahrnuje veřejnou stránku, bereme proto Lighthouse jako jeden ze zdrojů, nikoli jako celou diagnózu nebo záruku konkrétního skóre.

U databáze rozhoduje plán provedení, ne samotný seznam indexů

Databázové nástroje umožňují zjistit, jaký plán byl pro dotaz zvolen a co se během jeho vykonání skutečně stalo. PostgreSQL a MySQL k tomu poskytují příkazy z rodiny EXPLAIN. Přesné možnosti závisejí na použitém systému a verzi.

Takové měření pomáhá posoudit počet zpracovaných řádků, způsob spojování dat a místa, kde dotaz vykonává více práce, než se očekávalo. Přidání indexu není univerzální řešení: index musí odpovídat skutečnému dotazu a může ovlivnit také zápis dat.

Diagnostické metody volíme podle konkrétní databáze a prostředí. Na produkci nespouštíme náročné operace ani operace měnící data bez dohody o bezpečných podmínkách.

Co základní audit nezahrnuje

Pokud nabídka neurčí jinak, základní rozsah nezahrnuje:

• zavedení doporučených oprav;
• stálý monitoring a průběžnou údržbu aplikace;
• vybudování další infrastruktury pro rozsáhlé zátěžové testy;
• úplný bezpečnostní audit nebo kompletní audit aplikace vytvořené pomocí AI;
• záruku konkrétního skóre Lighthouse, doby odezvy nebo počtu obsloužených uživatelů;
• opravu částí, které nelze v dohodnutém prostředí bezpečně prověřit.

Pokud analýza ukáže potřebu větší přestavby, dalším krokem může být modernizace aplikace. Pro stálou péči, monitoring a správu změn je vhodná správa aplikací a e-shopů. Implementaci jednotlivých doporučení můžeme ocenit jako samostatnou etapu vývoje v PHP a Laravelu.

Doba, nabídka a platba

Audit oceňujeme individuálně, protože rozsah závisí na počtu zkoumaných procesů, technologiích, dostupných datech a podmínkách testu.

Orientačně počítáme s 5 až 10 pracovními dny od obdržení všech dohodnutých přístupů a podkladů. Přesný termín uvedeme v nabídce.

Platba obvykle následuje po dokončení dohodnuté etapy. U většího rozsahu můžeme sjednat zálohu. Pokud nám po auditu zadáte navazující projekt, cenu auditu započítáme do celkové ceny těchto prací.

Nejčastější otázky

Stačí poslat výsledek PageSpeed Insights nebo Lighthouse?

Taková zpráva může pomoci zahájit diskusi o veřejné stránce, ale nenahradí měření konkrétního procesu. Sama neodhalí příčinu pomalého reportu, importu, zápisu dat, fronty nebo operace po přihlášení.

Potřebujete přístup do produkce?

Ne vždy. Nejdříve zjistíme, kde lze problém bezpečně zopakovat. Upřednostňujeme testovací prostředí nebo kontrolované měření. Přístup do produkce domlouváme pouze tehdy, když je nezbytný a lze vhodně omezit.

Zahrnuje audit také zavedení oprav?

V základním rozsahu ne. Nejprve předáme diagnózu a priority. Implementaci můžeme ocenit samostatně a podklady můžete předat i jinému dodavateli.

Vyřeší přidání indexu problém s databází?

Někdy správný index pomůže, ale ne u každého dotazu a v každé situaci. Nejdříve prověříme plán provedení, množství zpracovaných dat a způsob, jakým aplikace dotaz používá.

Jaké technologie můžete prověřit?

Nejčastěji pracujeme s aplikacemi v PHP a Laravelu, e-shopy a souvisejícími databázemi. Jiný technologický stack posoudíme před oceněním, abychom neslibovali analýzu, kterou bychom nemohli spolehlivě provést.

Je audit možný bez předchozího monitoringu?

Ano, pokud lze problém zopakovat a máme dost podkladů pro měření. Pokud je dat málo, můžeme nejprve doporučit jejich bezpečný sběr. Toto omezení bude ve výsledku jasně uvedeno.

Co nám poslat na začátku

Ve formuláři popište:

• která činnost nebo část systému je pomalá;
• kdy problém vzniká a zda ho lze zopakovat;
• jak ovlivňuje zaměstnance, zákazníky nebo prodej;
• přibližný počet uživatelů, záznamů nebo operací, pokud ho znáte;
• používané technologie, pokud jsou známé;
• poslední větší změny v aplikaci nebo prostředí;
• dostupné zprávy a měření, ale bez důvěrných údajů.

Do formuláře neposílejte hesla, API klíče, kopie databáze ani údaje zákazníků. Bezpečný způsob předání potřebných materiálů domluvíme samostatně.

Pokud chcete nejprve uspořádat dostupné informace, použijte kontrolní seznam pro přípravu auditu výkonu. Nástroj problém nediagnostikuje a nevyžaduje odesílání důvěrných údajů.

CTA: Popsat problém s výkonem

Technické zdroje

• Google: Web Vitals - rozlišení dat od skutečných uživatelů a laboratorní diagnostiky včetně omezení běžného laboratorního měření INP.
• Google: Začínáme s měřením Web Vitals - důvody rozdílů mezi laboratorními výsledky a reálnými uživatelskými daty.
• PostgreSQL: Using EXPLAIN - plán provedení a skutečné údaje o běhu dostupné při analýze dotazu.
• MySQL 8.0: Obtaining Execution Plan Information - plán provedení a měření pomocí EXPLAIN ANALYZE.