---
title: "Prečo pokladňa zlyháva pri 10 % záťaži serverov"
description: "Nevyťažené servery, nedostupná pokladňa. Súperenie o zámky, cache stampede a synchrónne platobné volania, pred ktorými vás autoscaling nezachráni."
author: "Luboš Zápotočný"
published: "2026-06-04"
language: "sk"
canonical: "https://zapolu.com/sk/blog/preco-checkout-pada-v-spicke/"
---

# Prečo pokladňa zlyháva pri 10 % záťaži serverov

Je to najmätúcejší incident, aký môže e-commerce tím zažiť. Kampaň sa
spustí, pokladňa začne zlyhávať na timeouty a dashboardy trvajú na tom,
že je všetko v poriadku: CPU na 10 %, pamäť v poriadku, rezervy dosť.
Inštinkt velí pridať servery. Servery prídu, sú rovnako nevyťažené
ako tie ostatné a pokladňa je naďalej nedostupná.

Zmätok pramení zo zlého mentálneho modelu. Záťaž má dve zložky: prácu
a *čakanie*. Vaše servery stoja v rade, a rady na grafe CPU
nevidno.

## Časté príčiny

**Súperenie o databázové zámky.** Pokladňa je miesto, kde e-shop
prestáva čítať a začína zapisovať: rezervovať zásobu, vytvoriť
objednávku, uložiť adresu. Tieto zápisy sa serializujú na zámkoch
riadkov a kampaňová prevádzka sa pritom koncentruje na tých istých
pár riadkoch. Sto zákazníkov, ktorí prechádzajú pokladňou počas tej istej kampane,
sa serializuje na tých istých horúcich riadkoch: čítačoch poradia
objednávok, tabuľkách objednávok a košíkov, rezervovanej zásobe.
Každá transakcia drží svoje zámky, kým čaká na inú prácu.
Priepustnosť klesá, hoci CPU zostáva takmer nevyťažené. Na Magente to
má typický prejav: hlásenia o čakaní na zámky a deadlockoch, ktoré
ráno po výpredaji plnia logy.

**Cache stampede.** Horúci záznam v cache (stránka kategórie, na
ktorú mieri každá reklama) expiruje pod špičkovou prevádzkou. Každá
požiadavka, ktorá ho netrafí, teraz stránku regeneruje súčasne
a bombarduje databázu identickými drahými dopytmi. Cache, ktorá
e-shop zrýchlila, teraz spôsobí jeho výpadok, a kedy sa to stane, určuje jej TTL.

**Synchrónne volania tretích strán v ceste pokladne.** Sadzby
dopravy, autorizácia platby, výpočet dane, antifraud kontrola: každé
z nich je sieťové volanie do cudzieho systému, vykonané, kým váš
worker drží spojenie a často aj databázovú transakciu. Keď sa jeden
poskytovateľ pod tou istou kampaňovou záťažou spomalí z 200 ms na
10 sekúnd, každý worker postupne skončí zablokovaný v tom volaní.
Či a kedy budete mať výpadok, potom závisí od aktuálneho stavu
vášho dodávateľa.

**Vyčerpanie workerov a spojení.** Tri problémy vyššie zdieľajú
spoločný zosilňovač: workery, ktoré čakajú, stále obsadzujú svoj slot
aj svoje databázové spojenie. PHP-FPM procesy dimenzované na bežnú
prevádzku sa naplnia zablokovanými požiadavkami, nové požiadavky
nedostanú worker ani spojenie vôbec a zrazu je nedostupné *všetko*,
čo ešte potrebuje PHP worker, akokoľvek málo tá stránka robí.

Ani jeden z tých štyroch problémov nie je problém hardvéru, a práve
preto vás autoscaling nezachráni: nové inštancie sa zaradia do toho
istého radu na ten istý zámok riadku za tým istým pomalým dodávateľom.
Pridané inštancie len paralelizujú čakanie.

## Ako to zbadať vopred

Diagnostický posun je od *vyťaženia* k *času*. Kam idú milisekundy
požiadavky v pokladni: na prácu, alebo na čakanie na zámky, cache
a cudzie API? Distribuované trace na to odpovedajú priamo; slow-query
log plus čítače lock-wait v databáze na to odpovedajú lacno. Ak pred
ďalšou kampaňou pridáte len jeden graf, nech sú to čakania na zámky.

Opravy vyplývajú z diagnózy a väčšina z nich je neefektná: timeouty
na každom volaní tretej strany a cachované fallbacky tam, kde
zastaraná odpoveď neuškodí (mierne zastaraná sadzba dopravy nevadí,
autorizácia platby ale musí prebehnúť naživo), ochrana proti
stampede, aby horúci kľúč prestavoval jeden proces, kým ostatné
servírujú staršiu verziu, presun nepodstatných zápisov mimo
transakcie do fronty a rezervovanie zásoby tak neskoro vo funneli,
ako to biznis dovolí, namiesto jej držania už od košíka. Ktorá z nich je dôležitá pre váš e-shop, je empirická
otázka; [audit výkonu](/sk/services/performance-audit/) ju zodpovie
z vašich traceov, nie z cudzích skúseností, a naša
[DevOps práca](/sk/services/devops/) sa potom stará, aby oprava
vydržala.

Kampaňové zlyhania bývajú väčšinou zlyhaniami súbežnosti. Skôr než
objednáte ďalšie servery, pozrite sa do traceov, kam sa vám stráca
čas.