Latence (Latency)

Příklady z praxe

1. 01

   Sekvenční volání API zbytečně násobí odezvu

   Stránka s detailem objednávky načítá zákazníka, položky a dopravu třemi voláními za sebou. Při 120 ms na okružní cestu čeká uživatel 360 ms jen na síť, přestože dotazy na sobě nezávisí. Paralelizace zkrátí čekání na dobu nejpomalejšího z nich, tedy zhruba 120 ms.

   // špatně: 3 okružní cesty za sebou
   const customer = await fetch('/api/customer/42').then(r => r.json());
   const items = await fetch('/api/order/7/items').then(r => r.json());
   const shipping = await fetch('/api/order/7/shipping').then(r => r.json());
   
   // lépe: jedna okružní cesta v paralelu
   const [customer, items, shipping] = await Promise.all([
     fetch('/api/customer/42').then(r => r.json()),
     fetch('/api/order/7/items').then(r => r.json()),
     fetch('/api/order/7/shipping').then(r => r.json()),
   ]);

2. 02

   Průměr vypadá dobře, p99 pálí uživatele

   Monitoring hlásí průměrnou odezvu 90 ms a tým je spokojený. Po zapnutí percentilů se ukáže p99 na 2,4 sekundy: pomalé jsou dotazy zákazníků s velkou historií, kde chybí index. Průměr tuto skupinu utopil v datech, přestože jde o nejhodnotnější zákazníky.

   SELECT
     percentile_cont(0.5)  WITHIN GROUP (ORDER BY duration_ms) AS p50,
     percentile_cont(0.95) WITHIN GROUP (ORDER BY duration_ms) AS p95,
     percentile_cont(0.99) WITHIN GROUP (ORDER BY duration_ms) AS p99
   FROM request_log
   WHERE created_at > now() - interval '1 hour';

Časté omyly

MýtusMáme gigabitovou linku, takže latenci máme nízkou.

Ve skutečnostiKapacita linky a latence spolu přímo nesouvisí. Gigabitové satelitní připojení může mít odezvu přes 500 ms, zatímco pomalejší pozemní linka do sousedního datového centra jednotky milisekund. Šířka pásma řeší objem dat, ne dobu čekání na první bajt.

MýtusLatenci vyřešíme silnějším serverem.

Ve skutečnostiSilnější hardware pomůže jen tehdy, když je úzkým hrdlem výpočet. Pokud odezvu tvoří fyzická vzdálenost, počet okružních cest nebo čekání ve frontě u přetíženého zdroje, výkonnější stroj změní málo.

MýtusPing ukazuje latenci mojí aplikace.

Ve skutečnostiPing měří jen okružní cestu ICMP paketu k hostiteli. Skutečná odezva aplikace zahrnuje navíc navázání TCP a TLS spojení, zpracování na serveru, dotazy do databáze a vykreslení v prohlížeči, takže bývá násobně vyšší.

Časté dotazy

Jaká latence je pro webovou aplikaci ještě přijatelná?

Přijatelná latence závisí na typu interakce. Odezva do zhruba 100 ms působí okamžitě, do 300 ms je stále plynulá, nad jednu sekundu už uživatel vnímá čekání a přepíná pozornost jinam. U formulářů a vyhledávání s našeptávačem se cílí na desítky milisekund, u složitých reportů se toleruje i několik sekund, pokud aplikace ukáže průběh. Důležitější než jedno číslo je stabilita: kolísání odezvy mezi 50 a 2000 ms vnímají lidé hůř než konzistentních 400 ms.

Jak se latence měří v produkčním provozu?

Latence se v produkci měří na několika místech současně. Server zaznamenává dobu zpracování požadavku, reverzní proxy nebo load balancer čas včetně front, a měření na straně klienta (Real User Monitoring přes Performance API v prohlížeči) přidává síť a vykreslení. Distribuované trasování pak ukáže, kolik z celkové odezvy spotřebovala která služba. Data se agregují do histogramů a vyhodnocují percentily, ne průměry. Doplňkem je syntetické měření z různých geografických lokalit, které odhalí regionální problémy dřív než stížnosti uživatelů.

Proč latence roste, i když server není vytížený?

Latence roste i při zdánlivě nízkém vytížení kvůli frontám a sdíleným zdrojům. Průměrné využití procesoru 40 procent může skrývat krátké špičky, během nichž se požadavky hromadí. Dalšími viníky bývají vyčerpaný pool databázových spojení, zamykání v databázi, pauzy garbage collectoru, přeplněné buffery na síťových prvcích (bufferbloat) nebo pomalý externí API partner. Užitečné je proto sledovat vedle využití i délku front a dobu čekání na zámky.

Snižuje HTTP/3 latenci oproti HTTP/2?

HTTP/3 latenci obvykle snižuje, zejména na nestabilních sítích. Protokol běží nad QUIC, který slučuje navázání transportního a šifrovaného spojení do jedné okružní cesty a u opakovaných návštěv umožňuje odeslat data prakticky okamžitě. Zároveň odstraňuje blokování na úrovni TCP, kdy jeden ztracený segment pozdrží všechny souběžné streamy. Na kvalitní pevné lince bývá rozdíl malý, na mobilních sítích se ztrátovostí paketů znatelný. Přínos je ale menší než u optimalizací, které ubírají okružní cesty nebo přibližují obsah uživateli.

Zdroje

1. Latency (engineering)(otevře se v novém okně)Wikipedia
2. Performance API(otevře se v novém okně)MDN Web Docs
3. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport(otevře se v novém okně)IETF, 2021
4. PostgreSQL Documentation: Aggregate Functions(otevře se v novém okně)PostgreSQL Global Development Group

Související pojmy

• BackpressureBackpressure je mechanismus, kterým pomalejší část systému dává rychlejší části najevo, že má zpomalit, počkat nebo zahodit část práce. Používá se u streamů, front, sítí a event-driven aplikací, aby se nekonečně nehromadila data v paměti a aby přetížení nespadlo až na celý proces.
• CacheCache je mezipaměť, do které se ukládá výsledek náročné operace, aby se při dalším stejném dotazu nemusel počítat znovu. Vyměňuje čerstvost dat za rychlost a téměř vždycky přináší otázku, kdy uloženou hodnotu zahodit.
• Core Web VitalsCore Web Vitals je sada uživatelsky orientovaných metrik, kterými Google hodnotí rychlost načtení, odezvu na interakce a vizuální stabilitu webové stránky. V praxi jde hlavně o LCP, INP a CLS, tedy signály, které pomáhají odhalit pomalý obsah, zaseknuté rozhraní nebo poskakující layout.
• InferenceInference je fáze, kdy se už natrénovaný model, pravidlový systém nebo jiný mechanismus rozhodování použije na nová vstupní data a vrátí výsledek. Ve strojovém učení jde typicky o predikci, klasifikaci nebo generování odpovědi bez úpravy vah modelu, zatímco náklady řeší latence, paměť a provoz.
• PaketPaket je základní jednotka dat přenášená počítačovou sítí, složená z hlavičky s adresami a řídicími údaji a z užitečného obsahu. Odesílatel rozdělí zprávu na pakety, síť je doručuje nezávisle na sobě různými cestami a příjemce z nich původní data znovu poskládá do správného pořadí.
• BufferováníBufferování je dočasné shromažďování dat ve vyhrazené oblasti paměti (bufferu) mezi dvěma částmi systému, které pracují různou rychlostí nebo po různě velkých dávkách. Zápis se hromadí, dokud se buffer nezaplní nebo dokud ho program nevyprázdní, a teprve pak odchází dál. Cílem je méně drahých operací a plynulejší tok dat.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.