Vzorová správa z výkonnostného auditu

Toto je vzor. Klient „Acme Outdoor s.r.o.“ neexistuje a identifikačné údaje sú zmenené. Nálezy aj čísla sú anonymizované a poskladané zo skutočných výkonnostných auditov, ktoré Luboš Zápotočný odviedol počas desiatich rokov inžinierskej práce v e-commerce, ešte pred vznikom tejto praxe. Nejde o zákazky realizované pod značkou Zapolu, tá vlastnú klientsku históriu zatiaľ nemá; doklady o tejto skoršej práci nájdete na stránke O nás. Vzor ukazuje formát: čím je nález doložený, čo stojí jeho oprava a ako je práca zoradená. Správa, ktorú dostane klient, rozoberá každý nález rovnako podrobne ako nižšie F1; tento vzor šesť z jedenástich skracuje, aby zostal čitateľný.


Klient	Acme Outdoor s.r.o. (vymyslený)
E-shop	acme-outdoor.example (Magento 2.4.6, frontend Luma)
Stack	Varnish 7, Redis 7, MySQL 8, 2 aplikačné nody za load balancerom
Dátum správy	5. júna 2026
Dáta z reálnej prevádzky	7. mája až 3. júna 2026 (28 dní)
APM trace	21. mája až 3. júna 2026 (14 dní) a jeden záťažový test
Nástroje	New Relic, CrUX, Lighthouse, k6, varnishstat, MySQL slow log
Autor	Luboš Zápotočný, Zapolu s.r.o.
Zákazka	Deep dive, 7 pracovných dní, fixná cena

Pre stručný prehľad si prečítajte kapitolu 1 a kapitolu 5. Text medzi nimi tvorí podklady k jednotlivým nálezom.

1. Zhrnutie

Pomalosť e-shopu vzniká na strane servera. LCP z dát z reálnej prevádzky je na katalógových stránkach 4,6 s na p75 (cieľ: ≤ 2,5 s); jeho hlavnou príčinou je TTFB 1,9 s. TTFB je vysoké preto, že full-page cache je fakticky vypnutá: Varnish obsluhuje len 34 % katalógových požiadaviek a 38 % všetkého serverového času pripadá na vykresľovanie produktových stránok, v priemere 2,2 s na požiadavku. Počas kampaňového večera 26. mája dosiahol checkout p95 6,1 s a 3,4 % požiadaviek zlyhalo, zatiaľ čo CPU aplikačných serverov neprekročilo 12 %.

Nasleduje jedenásť nálezov. Sedem z nich stojí deň práce alebo menej a dva z tých siedmich (F2 a F8) sú zmeny len v konfiguračných súboroch. Riadky 1 až 6 plánu opráv odstránia všetky zlyhania, ktoré zákazník pocíti: checkout prestane v špičke zlyhávať a checkout p95 počas kampaní klesne zo 6,1 s na 1,9 s. Largest Contentful Paint sa len s týmito riadkami pod hranicu 2,5 s stanovenú Googlom nedostane. Rozpočet:

Stav	Čo sa mení	LCP kategórie	LCP produktu
dnes		4,6 s	4,6 s
po riadku 2	F1, TTFB katalógu 1,9 s → 1,2 s	3,9 s	3,9 s
po riadku 5	F5, hero obrázky produktov	3,9 s	3,3 s
po riadku 7	F4 dočasne, mŕtve tagy a odklad	3,5 s	2,9 s
po riadku 8	F4, prestavba frontendu	2,7 s	2,1 s

Pod prah dostane produktové stránky až prestavba v riadku 8. Kategórie končia na 2,7 s, teda stále nad prahom; čo by zvyšok dorovnalo, sme nezisťovali (kapitola 6). Riadky sú zoradené podľa návratnosti, takže plán možno kedykoľvek zastaviť.

Prepočítané na peniaze: počas troch hodín kampane večer 26. mája skončilo chybou zhruba 230 checkoutov. Pri priemernej hodnote objednávky 1 800 Kč to predstavuje 414 000 Kč v objednávkach, ktoré zlyhali, teda asi 17 000 € pri kurze 24,3 Kč za euro, a nezaratáva to zákazníkov, ktorí checkout po šiestich sekundách čakania opustili. Ostatné nálezy uvádzame v milisekundách; suma v peniazoch by pri nich bola špekulatívna, preto ju neuvádzame.

2. Čo a ako sme merali

Metriky reálnych používateľov: Core Web Vitals z 28-dňového CrUX dotazu, segmentované podľa typu stránky (homepage / kategória / produkt / checkout). Syntetické Lighthouse behy slúžili len na reprodukciu nálezov, nie na ich hodnotenie. Ako si e-shop stojí proti prahovým hodnotám Googlu:

Metrika (p75, dáta z reálnej prevádzky) E-shop Prah Verdikt
LCP 4,6 s < 2,5 s neprešlo
INP 280 ms < 200 ms neprešlo
CLS 0,04 < 0,1 prešlo
FCP 2,9 s < 1,8 s neprešlo
TTFB 1,9 s < 0,8 s neprešlo
Trasovanie na serveri: transakčný profil z New Relic za 14 dní, teda kam serverový čas naozaj ide:

Transakcia Podiel serverového času Priemerná odpoveď
catalog/product/view 38 % 2,2 s
catalog/category/view 17 % 1,8 s
checkout REST (košík + doprava) 11 % 1,4 s (6,1 s p95 v špičke)

K tomu MySQL slow query log, profil volaní externých služieb a štatistiky hit/miss Varnishu podľa URL vzorov z varnishstat.
Záťažový test: replay priebehu prevádzky z kampane večer 26. mája (0 → 420 req/s počas 20 minút) proti stagingu s rovnakým stavom cache ako v produkcii.
Revízia konfigurácie: nastavenia PHP a OPcache, Composer autoloader, env.php, Varnish VCL a nastavenia MySQL, každé proti dokumentovaným odporúčaniam pre Magento, navýšeným tam, kde kódová základňa dokumentovanú hodnotu prerastá.
Audit bundlov a assetov: čo sa posiela pri prvom zobrazení produktovej stránky, čo blokuje vykreslenie a čo je zbytočná záťaž.

Metrika (p75, dáta z reálnej prevádzky)	E-shop	Prah	Verdikt
LCP	4,6 s	< 2,5 s	neprešlo
INP	280 ms	< 200 ms	neprešlo
CLS	0,04	< 0,1	prešlo
FCP	2,9 s	< 1,8 s	neprešlo
TTFB	1,9 s	< 0,8 s	neprešlo

Transakcia	Podiel serverového času	Priemerná odpoveď
`catalog/product/view`	38 %	2,2 s
`catalog/category/view`	17 %	1,8 s
checkout REST (košík + doprava)	11 %	1,4 s (6,1 s p95 v špičke)

Pri väčšine nálezov citujeme presný príkaz alebo dotaz, ktorý sme použili, jednak aby si váš tím mohol našu prácu skontrolovať, jednak preto, že rovnaké sondy pobežia na ktoromkoľvek Magento e-shope, vrátane toho vášho. Kapitola 7 ich zbiera tak, aby sa dali spustiť bez zmeny. Pri každom čísle nižšie je uvedené, odkiaľ pochádza, a tabuľka nálezov má stĺpec, ktorý hovorí, či bol očakávaný dopad zmeraný, reprodukovaný v záťaži, alebo odhadnutý.

3. Prehľad nálezov

Vysoká: dopadá na zákazníkov, alebo na nej závisia tržby. Stredná: denne ju pociťuje tím, alebo ticho poškodzuje dáta. Nízka: málo úsilia, ktoré odstráni reálne prevádzkové riziko.

#	Nález	Závažnosť	Prácnosť	Očakávaný dopad	Podklad
F1	Full-page cache je fakticky vypnutá a nedá sa invalidovať	Vysoká	1–2 dni	−700 ms TTFB na p75 v katalógu	zmerané
F2	PHP runtime a autoloader zle nastavené pre Magento	Vysoká	0,5 dňa	−400 ms na každej necachovanej požiadavke	odhad
F3	Checkout blokuje synchrónny dotaz na sklad v ERP	Vysoká	3–5 dní	−2,8 s checkout p95 v špičke; koniec timeoutových chýb	záťažový test
F4	Frontend posiela 2,3 MB JavaScriptu, blokuje vykreslenie	Vysoká	projekt	−1,2 s LCP (dočasné zmiernenia: −0,4 s)	odhad
F5	Produktové obrázky: 1,6MB PNG, bez responzívnych veľkostí	Stredná	1 deň	−0,6 s LCP na produktových stránkach	zmerané
F6	Indexery ponechané na „Update on Save“	Stredná	0,5 dňa	Uloženie v admine 30 s → ~2 s; koniec nesúladu skladových stavov	odhad
F7	PHP-FPM pool vyčerpaný session lockmi v špičke	Vysoká	2 dni	Checkout prežije kampaňovú prevádzku	záťažový test
F8	Varnish bez grace módu	Nízka	0,5 dňa	Stlmí nápor po každom flushi cache	odhad
F9	Dve extenzie počúvajú rovnaký event; jedna je opustená	Stredná	1 deň	−300 ms na pridanie do košíka	zmerané
F10	41 GB mŕtvych indexerových temp tabuliek v MySQL	Nízka	0,5 dňa	Zálohy o 60 % menšie; obnova zhruba za polovicu času	zmerané
F11	Order grid v admine filtruje cez neindexovaný stĺpec	Nízka	0,5 dňa	Grid objednávok 12 s → pod 1 s	odhad

Podklad hovorí, odkiaľ očakávaný dopad pochádza. Zmerané: videli sme to na tomto e-shope. Záťažový test: reprodukovali sme to na stagingu pri záťaži zodpovedajúcej kampani. Odhad: plynie z profilu a konfigurácie a nikto to zatiaľ nepozoroval.

4. Nálezy podrobne

F1: Full-page cache je fakticky vypnutá a nedá sa invalidovať (Vysoká)

Čo sme videli. Varnish hlási na katalógových URL hit rate 34 %. Pre katalóg tejto veľkosti a s týmto podielom crawlerov je bežná hodnota nad 90 %. Každá kategória aj produktová stránka nesie X-Magento-Cache-Debug: MISS. Príčiny sú dve nezávislé:

Upravený default.xml označuje jeden blok v hlavičke (prepínač store view, ktorý číta zákaznícku session) ako cacheable="false". V Magente jediný necachovateľný blok v layoute urobí necachovateľnou celú stránku. Blok pribudol s aktualizáciou extenzie v novembri 2025; hit rate sa zrútil v ten istý týždeň.
Varnish je zapnutý v administrácii (system/full_page_cache/caching_application = 2), ale v env.php chýba sekcia http_cache_hosts, takže Magento vôbec nevie posielať purge požiadavky do Varnishu. Tím to obchádza reštartom Varnishu po každom deployi, a práve preto sú deploye problematické (pozri F8).

Ako sme to overili:

$ curl -sI https://acme-outdoor.example/stany | grep -i cache-debug
X-Magento-Cache-Debug: MISS
# rovnako na každej katalógovej URL

$ grep -R 'cacheable="false"' app/design app/code | wc -l
1
# prepínač store view v default.xml

$ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));'
false
# Magento nevie poslať purge do Varnishu

Oprava. Vykresliť prepínač cez private content (customer data JS), takže stránka zostane cachovateľná (dokumentovaný vzor pre fragmenty závislé od session), a doplniť http_cache_hosts do env.php, aby fungovala invalidácia cez tagy a reštarty mohli skončiť.

Prácnosť / dopad / riziko. 1–2 dni vrátane regresných testov. Očakávaných −700 ms TTFB na p75 katalógu (zmerané: cachovaná katalógová odpoveď sa vracia za 80 ms, necachovaná za 1,9 s). Riziko: nízke; obe zmeny sú ohraničené a vratné po jednotlivých deployoch.

F2: PHP runtime a autoloader zle nastavené pre Magento (Vysoká)

Čo sme videli. Základňa kódu obsahuje ~125 000 PHP súborov; OPcache je nastavená na 10 000. Composer autoloader nebol nikdy optimalizovaný: vendor/composer/autoload_static.php neobsahuje mapu tried a v New Relic trace vidno celé sekundy, ktoré ObjectManager strávi skladaním inštancií pri prvých požiadavkách, kým sa vyrovnávacia pamäť tried nenaplní. Aktuálny stav a odporúčanie:

Nastavenie	Aktuálne	Odporúčané
`opcache.max_accelerated_files`	10 000	100 000
`opcache.memory_consumption`	128	512
`opcache.validate_timestamps`	On, revalidácia každé 2 s	Off; reset pri deployi
`opcache.enable_cli`	Off	On (indexery a crony sú tiež PHP)
`realpath_cache_size`	4M	32M
`realpath_cache_ttl`	120	7200
Composer autoloader	neoptimalizovaný	`dump-autoload --optimize` v builde

Ako sme to overili:

$ find . -type f -name '*.php' | wc -l
124862
# PHP súborov v codebase

$ php -i | grep 'opcache.max_accelerated_files'
opcache.max_accelerated_files => 10000
# pojme 8 % z nich

$ grep -c 'classMap' vendor/composer/autoload_static.php
0
# autoloader nebol nikdy optimalizovaný

Prečo. S týmito hodnotami PHP priebežne nanovo statuje a prekladá veľkú časť codebase; profily pripisujú vyše polovicu času necachovaného renderu načítavaniu tried a skladaniu stránky namiesto obchodnej logiky.

Oprava. Jedna zmena konfigurácie plus jeden krok v builde. Jediná väzba, ktorú treba rešpektovať: s vypnutým validate_timestamps musí deploy pipeline pri release resetovať OPcache. Presný krok pre vašu súčasnú pipeline sme popísali v pláne opráv.

Prácnosť / dopad / riziko. 0,5 dňa. Odhadom −400 ms na každej necachovanej požiadavke (a rýchlejšie crony a indexery ako vedľajší efekt). Riziko: nízke, pokiaľ krok v deployi pristane spolu s konfiguráciou.

F3: Checkout blokuje synchrónny dotaz na sklad v ERP (Vysoká)

Čo sme videli. Vo fáze dopravy ukazuje trace synchrónne HTTPS volanie na skladový endpoint ERP s 3-sekundovým timeoutom a jedným opakovaním; profil externých služieb pripisuje tomuto jedinému endpointu 92 % všetkého čakania na externé systémy. Pri kampaňovej záťaži sa ERP spomalí, volania vyčerpajú celý časový limit a požiadavky checkoutu sa začnú hromadiť. Presne odtiaľ pochádza p95 6,1 s aj 3,4 % zlyhaní. Záťažový test to na stagingu reprodukuje.

Prečo. Potvrdzovanie skladu v reálnom čase pribudlo po incidente s prepredajom v roku 2025. Zámer je správny, len vkladá latenciu cudzieho systému do každého checkoutu.

Oprava. Presunúť porovnávanie skladu mimo požiadavky: rezervovať voči lokálnemu stavu zásob, potvrdzovať asynchrónne a upozorňovať na nesúlad skladových stavov. Ochrana proti prepredaju zostane zachovaná a checkout prestane na ERP čakať. Rovnaký vzor rozoberáme v článku prečo sa ERP a e-shop nezhodnú na sklade.

Prácnosť / dopad / riziko. 3–5 dní vrátane alertu na nesúlad stavov. Odstráni ~2,8 s z checkout p95 v špičke a timeoutové zlyhania úplne (oboje zmerané v záťažovom teste so zaslepeným volaním). Riziko: stredné; vyžaduje písomné odsúhlasenie nového okna prepredaja (odhadom < 0,1 % kampaňových objednávok, oproti dnešným 3,4 % zlyhávajúcich checkoutov).

F4: Frontend posiela 2,3 MB JavaScriptu (Vysoká)

Čo sme videli. Prvé zobrazenie produktovej stránky stiahne 2,3 MB JavaScriptu v 61 súboroch; blokovanie hlavného vlákna trvá na bežnom telefóne 2,9 s. Za štyrmi zo štrnástich marketingových tagov už nestojí funkčný účet.

Prečo. Sčasti architektúra frontendu Luma, sčasti osem rokov hromadenia tagov; žiaden z nich sám osebe neprevažuje.

Oprava, krátkodobo (tento kvartál). Odstrániť štyri mŕtve tagy, odložiť analytický bundle, lenivo načítavať widget recenzií nižšie na stránke. Odhadom −0,4 s LCP, 2 dni.

Oprava, skutočná (samostatné rozhodnutie). Prestavba frontendu na Hyvä. Nahrádza javascriptovú vrstvu Lumy, namiesto toho, aby jej časti len odkladala, takže o objeme payloadu rozhoduje architektúra, nie správa jednotlivých tagov. Je to projekt na 6–10 týždňov a zaslúži si vlastné nacenenie, nie riadok v zozname opráv. Uvádzame ho tu, aby sa krátkodobý odhad vyššie nechápal ako dosiahnuteľné maximum.

F7: PHP-FPM pool vyčerpaný session lockmi v špičke (Vysoká)

Čo sme videli. Počas záťažového testu začínajú zlyhania okolo 280 req/s, zatiaľ čo CPU sedí na 12 %. Status FPM ukazuje všetkých workerov obsadených; trace ukazujú čakanie na session locky v Redise: zákazníci, ktorí sa opakovane dopytujú stránky potvrdenia objednávky, držia zámky, ktoré radia do frontu všetky ďalšie požiadavky tej istej session.

Oprava. Vypnúť zamykanie session pre endpointy opakovaného dopytovania, zvýšiť počet workerov na to, čo pamäťová rezerva reálne dovolí (dnešné číslo pochádza z menšieho typu inštancie), a pridať alert na vyťaženie FPM; tento výpadok zostal nepovšimnutý, lebo grafy CPU nevyzerali podozrivo.

Prácnosť / dopad / riziko. 2 dni vrátane zopakovania záťažového testu. Spolu s F3 prežije staging 420 req/s s checkout p95 1,9 s. Riziko: nízke.

F5, F6, F8, F9, F10, F11 stručne

F5 Obrázky: produktové hero obrázky sú 1,6MB PNG doručované v jednej veľkosti všetkým zariadeniam. Konverzia do WebP + responzívne veľkosti cez CDN: 1 deň, −0,6 s LCP na produktových stránkach (zmerané na skonvertovanej vzorke).
F6 Indexery: prepnuté na „Update on Save“ pri hromadnom importe vo februári 2026 a už nikdy späť. Uloženie produktu v admine trvá 30 s a nesúlad medzi skladom na webe a realitou v sklade pochádza z race conditions pri reindexe. Vrátiť plánované indexovanie: 0,5 dňa. Tých 30 s je zmeraných; číslo po oprave je odhad.
F8 Varnish grace: každý flush cache dnes pošle celú vlnu prevádzky na PHP. Grace mód vracia staré objekty, kým sa cache znovu nenaplní: 0,5 dňa. Dopad je odhad.
F9 Duplicitné observery: dve extenzie odoberajú rovnaký checkout event; jednu vendor opustil v roku 2023 a pri každom volaní nanovo načítava quote. Odstrániť ju (jej funkcia sa nepoužíva): 1 deň vrátane overenia, −300 ms na pridanie do košíka (zmerané v trace).
F10 Upratovanie databázy: databáza nesie 41 GB tabuliek catalogrule_product__temp* (pozostatky nedobehnutých indexerov zo staršej verzie Magenta, ktorá po sebe neupratovala) plus vlastnú tabuľku fronty s 12 miliónmi riadkov bez akejkoľvek retencie. Nájde ich jedna query do information_schema:
```
mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length)
    -> /1024/1024/1024, 1) gb FROM information_schema.tables
    -> WHERE table_name LIKE 'catalogrule\_product\_\_temp%';
+--------+------+
| tables | gb   |
+--------+------+
|     96 | 41.2 |
+--------+------+
```
Zmazanie pozostatkov a doplnenie čistenia: 0,5 dňa. Zálohy sa zmenšia zo 68 GB na 27 GB; obnova potom trvá zhruba polovicu času, čo je odhad zo zmeny veľkosti a ráta sa hlavne v deň, keď obnovu naozaj potrebujete.
F11 Order grid v admine: stĺpec pridaný pre expedíciu filtruje podľa neindexovaného atribútu; grid sa načítava 12 s a zakaždým blokuje jedného workera. Jedna indexová migrácia: 0,5 dňa. Tých 12 s je zmeraných; číslo po oprave je odhad.

5. Plán zoradený podľa návratnosti

Poradie	Položky	Prácnosť	Čo získate
1	F2 + F8	1 deň	Každá necachovaná požiadavka −400 ms; flushe cache už nevyvolajú špičku záťaže
2	F1	1–2 dni	TTFB katalógu −700 ms; deploye už nevyžadujú reštart Varnishu
3	F6 + F10 + F11	1,5 dňa	Použiteľný admin; koniec nesúladu skladových stavov; zálohy na polovicu
4	F7	2 dni	Checkout prestane v špičke zlyhávať
5	F5 + F9	2 dni	LCP produktovej stránky −0,6 s; pridanie do košíka −300 ms
6	F3	3–5 dní	Checkout p95 pod 2 s počas kampaní
7	F4 krátkodobo	2 dni	LCP −0,4 s, kým padne rozhodnutie o frontende
8	F4 prestavba	samostatné nacenenie	LCP produktových stránok pod prahom 2,5 s

Riadky 1–6 dajú dohromady 10,5 až 13,5 inžinierskeho dňa a riešia všetky zlyhania, ktoré zákazník pocíti. Po ktoromkoľvek riadku môžete skončiť a práca do tej chvíle obstojí sama o sebe. Riadok 6 ako jediný zasahuje do architektúry objednávkovej cesty; nech ho vykoná ktokoľvek, dajte návrh posúdiť seniornému inžinierovi.

Po riadku 6 premerajte tým istým dotazom na dáta z reálnej prevádzky, ktorým sa táto správa začala. Ak sa čísla nepohnú podľa predikcie, kontaktujte nás a zistíme príčinu.

6. Čo sme nekontrolovali

Bezpečnosť, SEO, prístupnosť a kvalita kódu mimo profilovaných najvyťaženejších miest kódu sú mimo rozsahu tejto zákazky. Audit pokrýva predvolený store view; B2B store view zdieľa stack, ale nemerali sme ho zvlášť. Rozpočet z kapitoly 1 necháva kategórie 0,2 s nad prahom 2,5 s a nezisťovali sme, čím je ten rozdiel daný: vyžaduje si to prechod šablónami kategórií, čo táto zákazka nezahŕňala. Jedno obmedzenie prístupov: náš auditný používateľ sa počas okna nedostal k admin socketu Varnishu, takže runtime čítače Varnishu pochádzajú zo snapshotov varnishstat, ktoré nám exportoval hosting, nie z priamej kontroly v reálnom čase.

7. Príloha: sondy, ktoré si môžete spustiť sami

Toto sú read-only kontroly, ktorými tento audit začínal. Pobežia na ktoromkoľvek Magente 2 a nepotrebujú nič iné než shell a databázového klienta. Spustite si ich skôr, než si u kohokoľvek objednáte audit, u nás tiež: ak sú všetky výsledky v poriadku, problém je niekde, kam táto správa nesiaha.

1. Obsluhuje full-page cache naozaj? Vyžiadajte si katalógovú URL dvakrát a prečítajte si debug hlavičku.

$ curl -sI https://vas-eshop.example/nejaka-kategoria | grep -i cache-debug

V poriadku: HIT na druhý pokus. MISS zakaždým je F1.

2. Nerobí niečo stránky necachovateľnými? Jediný blok s cacheable="false" kdekoľvek v layoute urobí necachovateľnou celú stránku.

$ grep -R 'cacheable="false"' app/design app/code | wc -l

V poriadku: 0.

3. Vie Magento vôbec purgovať Varnish?

$ php -r 'var_export(array_key_exists("http_cache_hosts", (include "app/etc/env.php")));'

V poriadku: true, ak je nastavenou cache Varnish.

4. Pojme OPcache celú codebase? Porovnajte obe čísla.

$ find . -type f -name '*.php' | wc -l
$ php -i | grep 'opcache.max_accelerated_files'

V poriadku: druhé číslo je väčšie než prvé.

5. Optimalizuje build Composer autoloader?

$ grep -c 'classMap' vendor/composer/autoload_static.php

V poriadku: čokoľvek iné než 0.

6. Bežia indexery podľa plánu?

$ php bin/magento indexer:show-mode

V poriadku: každý riadok hlási „Update by Schedule“. Čokoľvek na „Update on Save“ je F6. (Názov príkazu aj názvy režimov podľa referenčnej príručky Adobe k indexerom, overené 1. augusta 2026.)

7. Koľko mŕtvej váhy je v databáze?

mysql> SELECT COUNT(*) tables, ROUND(SUM(data_length+index_length)
    -> /1024/1024/1024, 1) gb FROM information_schema.tables
    -> WHERE table_name LIKE '%\_\_temp%';

V poriadku: pár tabuliek. E-shop v tejto správe ich mal 96, o 41 GB.

8. Na čo čaká checkout? Táto sonda potrebuje APM, nie shell: otvorte transakciu checkoutu, zoskupte podľa externej služby a prečítajte si podiel na celkovom čase. V tejto správe pripadalo na jediný endpoint 92 % toho času, čo je F3.

8. Ďalšie kroky

Plán opráv zvládne vykonať ktorýkoľvek kompetentný tím vrátane vášho: každý nález pomenúva konkrétnu zmenu, ktorú treba urobiť. Ak ho máme vykonať my, riadky 1–6 sa zmestia do dvoj- až trojtýždňovej zákazky za fixnú cenu podľa našich štandardných podmienok spolupráce.

Otázky k jednotlivým nálezom: info@zapolu.com, alebo si dohodnite hovor a prineste vlastné čísla; na hovore vám priamo povieme, či má audit zmysel.