Jak zkontrolovat dobu odezvy serveru

Doba odezvy, TTFB a načtení stránky nejsou totéž číslo

Používají se zaměnitelně, přitom odpovídají na různé otázky:

• Doba připojení je DNS překlad plus TCP handshake plus TLS handshake. Je to hlavně vzdálenost a kvalita sítě, a vlastní kód serveru s tím nemá nic společného.
• Time to first byte (TTFB) je okamžik, kdy dorazí první bajt odpovědi, měřeno od začátku požadavku. Zahrnuje dobu připojení plus zpracování na serveru: routování, databázové dotazy, vykreslení šablony, případná volání navazujících API.
• Doba zpracování na serveru je TTFB minus doba připojení. Tohle je ta část, kterou dokážete opravit ve vlastní aplikaci.
• Doba načtení stránky je úplně všechno: HTML, pak každý obrázek, styl, skript a font, který si prohlížeč stáhne, plus práce s jejich vykreslením. Stránka může mít vynikající TTFB a přesto se načítat osm sekund.

Když se tyto pojmy pletou, lidé optimalizují špatnou věc. Komprese obrázků nic nezmění na pomalém databázovém dotazu, a rychlejší databáze nic nezmění na stránce se čtyřmi megabajty JavaScriptu.

Měření pomocí curl

curl hlásí každou fázi zvlášť, takže jedním příkazem oddělíte náklady na připojení od nákladů na server:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Všechny hodnoty jsou v sekundách od začátku požadavku, takže každá zahrnuje ty předchozí. Zpracování na serveru je ttfb minus tls, nebo minus connect u obyčejného HTTP. Spusťte to třikrát nebo čtyřikrát: první požadavek může doplatit na studenou cache nebo nové spojení, a jeden vzorek není měření.

Dvě věci si pamatujte. Tohle měří jen HTML dokument, ne celou stránku, takže to bude vždy vypadat rychleji než test v prohlížeči. A necachovaná, přihlášená nebo vyhledávací stránka bývá výrazně pomalejší než domovská stránka, takže měřte URL, na které vám skutečně záleží, ne /.

Co se počítá jako normální

Univerzální práh neexistuje. Tato pásma jsou rozumné vodítko pro požadavek na dokument měřený z lokality blízko vašich návštěvníků:

• Pod 200 ms. Rychlé. Typické pro statický obsah, teplou cache, nebo edge uzel CDN odpovídající přímo.
• 200 až 500 ms. Normální pro dynamickou stránku, která se dotazuje databáze. Tohle si nikdo nevšimne.
• 500 ms až 1 s. Znatelné. Obvykle dotaz, který potřebuje index, necachovaná šablona, nebo pomalé navazující volání.
• 1 až 3 s. Uživatelé to cítí a vyhledávače to měří. Stojí za to řešit to jako závadu.
• Přes 3 s. Něco je špatně: přetížený server, zámek, timeout navazující služby, nebo požadavek, který dělá mnohem víc práce, než by měl.

Mnohem užitečnější je porovnání sami se sebou. Stránka, která minulý měsíc odpovídala za 300 ms a dnes odpovídá za 900 ms, má konkrétní příčinu, která mezitím nastala, a vědět to je cennější než jakýkoli publikovaný benchmark.

Proč se to liší podle lokality

Vzdálenost stojí čas a nedá se optimalizací obejít. Každá zpáteční cesta mezi klientem a serverem trvá minimálně tolik, kolik dovolí fyzická trasa, a TLS spojení potřebuje několik zpátečních cest, než vůbec může začít první bajt odpovědi. Proto může stejný server odpovídat za 150 ms lokálně a za 700 ms z jiného kontinentu, přestože dělá naprosto stejnou práci.

Na routování záleží také, a je méně předvídatelné než vzdálenost: provoz mezi dvěma sítěmi může jít po špatné trase, která přidá latenci jednomu regionu a nikomu jinému. Pokud používáte CDN, některé lokality jsou obslouženy z blízké cachované kopie, zatímco jiné cache minou a zaplatí celou cestu k originu, což vytvoří velký rozptyl mezi lokalitami pro stejnou URL.

Měřte tedy odtud, kde jsou vaši uživatelé, ne odtud, kde je váš server, a porovnávejte srovnatelné se srovnatelným. Číslo bez uvedené lokality se nedá s ničím porovnat.

Kdy pomalé znamená rozbité

Některá pomalost je spíš varování než výkonnostní problém:

• Doba odezvy, která pod zátěží stále roste, znamená přetížený server. Skončí to timeouty, ne jen pomalými stránkami.
• Časy nahloučené přesně na 30 nebo 60 sekundách jsou timeouty, ne pomalost. Něco navazujícího neodpovídá a proxy čeká na svůj limit, než se vzdá s 504.
• Většinu času rychlé s příležitostnými velkými výkyvy obvykle ukazuje na zámek, cron úlohu, zálohu, nebo vypršení cache, kterou najednou znovu sestavuje každý požadavek.
• Pomalé jen pro přihlášené uživatele znamená, že cache nese anonymní provoz a skrývá pod sebou skutečně pomalou aplikaci.
• Pomalé jen z jednoho regionu je problém sítě nebo CDN, ne aplikace, a žádná práce na backendu to nevyřeší.

Jak si všimnout dne, kdy se to změnilo

Jedno měření vypovídá jen o tom, co se stalo u jednoho požadavku, z jednoho místa, v jednom okamžiku, a doba odezvy je přesně ten typ metriky, která se spíš pozvolna posouvá, než že by náhle spadla. Naplánované kontroly měří stejnou URL ze stejných lokalit nepřetržitě, udržují historii, ve které lze dohledat den, kdy se to změnilo, a upozorní, když čas překročí práh, místo aby to bylo až po stížnosti zákazníka. HostTracker tyto kontroly spouští z více než 300 kontrolních bodů ve 158 městech, takže regionální zpomalení je vidět jako regionální. Spusťte kontrolu hned pomocí nástroje HTTP kontroly. Pokud je server rychlý, a stránka přesto ne, zbytek odpovědi najdete v návodu jak zkontrolovat rychlost webu.