--- title: "Vzorová správa z výkonnostného auditu" description: "Kompletný výstup výkonnostného auditu Magenta na vymyslenom e-shope: jedenásť nálezov, pri každom doklad, cena opravy a plán zoradený podľa návratnosti. Na konci sú sondy, aby ste si rovnaké kontroly spustili na svojom e-shope." language: "sk" canonical: "https://zapolu.com/sk/downloads/sample-audit-report/" --- # Výkonnostný audit: deep dive (vzorová správa) > **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](https://zapolu.com/sk/about/). 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ž. 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é: 1. 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ň. 2. 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](https://zapolu.com/sk/blog/preco-sa-erp-a-eshop-nezhodnu-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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/manage-indexers), 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](https://zapolu.com/sk/downloads/zapolu-engagement-template.pdf). Otázky k jednotlivým nálezom: [info@zapolu.com](mailto:info@zapolu.com), alebo si [dohodnite hovor](https://zapolu.com/sk/contact/) a prineste vlastné čísla; na hovore vám priamo povieme, či má audit zmysel.