Hoe u de serverresponstijd controleert

Responstijd, TTFB en paginalaadtijd zijn niet hetzelfde getal

Ze worden door elkaar gebruikt en beantwoorden verschillende vragen:

• Verbindingstijd is DNS-resolutie plus de TCP-handshake plus de TLS-handshake. Dat is vooral afstand en netwerkkwaliteit, en de eigen code van de server heeft er niets mee te maken.
• Time to first byte (TTFB) is het moment waarop de eerste byte van het antwoord aankomt, gemeten vanaf het begin van het verzoek. Het omvat de verbindingstijd plus de verwerking van de server: routering, databasequery's, het renderen van templates, elke upstream-API-aanroep.
• Serververwerkingstijd is TTFB min verbindingstijd. Dit is het deel dat u in uw applicatie kunt repareren.
• Paginalaadtijd is alles: de HTML, en dan elke afbeelding, stylesheet, script en font die de browser ophaalt, plus het werk om ze te renderen. Een pagina kan een uitstekende TTFB hebben en toch acht seconden nodig hebben om te laden.

Ze door elkaar halen zet mensen aan het optimaliseren van het verkeerde. Afbeeldingen comprimeren doet niets voor een trage databasequery, en een snellere database doet niets voor een pagina met vier megabyte JavaScript.

Het meten met curl

curl rapporteert elke fase apart, waardoor u verbindingskosten en serverkosten in één commando kunt scheiden:

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/

Alle waarden zijn seconden vanaf het begin van het verzoek, dus elke waarde omvat de vorige. Serververwerking is ttfb min tls, of min connect bij gewone HTTP. Voer het drie of vier keer uit: het eerste verzoek betaalt mogelijk voor een koude cache of een verse verbinding, en één meting is geen meting.

Twee dingen om uit elkaar te houden. Dit meet alleen het HTML-document, niet de pagina, dus het zal altijd sneller lijken dan een browsertest. En een ongecachete, ingelogde of zoekpagina is vaak drastisch trager dan de homepage, dus meet de URL waar het u om gaat in plaats van /.

Wat als normaal geldt

Er is geen universele drempel. Deze bandbreedtes zijn een redelijke leidraad voor een documentverzoek gemeten vanaf een locatie dicht bij uw bezoekers:

• Onder de 200 ms. Snel. Typisch voor statische content, een warme cache, of een CDN-edge die rechtstreeks antwoordt.
• 200 tot 500 ms. Normaal voor een dynamische pagina die een database bevraagt. Niemand merkt dit.
• 500 ms tot 1 s. Merkbaar. Meestal een query die een index nodig heeft, een ongecachete template, of een trage upstream-aanroep.
• 1 tot 3 s. Gebruikers voelen het, en zoekmachines meten het. De moeite waard om als defect te behandelen.
• Boven de 3 s. Er is iets mis: een verzadigde server, een lock, een upstream-dienst die een time-out geeft, of een verzoek dat veel meer werk doet dan het zou moeten.

De veel nuttigere vergelijking is met uzelf. Een pagina die vorige maand in 300 ms antwoordde en vandaag in 900 ms antwoordt, heeft een specifieke oorzaak die ertussenin is opgetreden, en dat weten is meer waard dan elke gepubliceerde benchmark.

Waarom het per locatie verschilt

Afstand kost tijd en kan niet worden wegge-optimaliseerd. Elke rondreis tussen client en server duurt minstens zo lang als het fysieke pad toelaat, en een TLS-verbinding heeft meerdere rondreizen nodig voordat de eerste byte van het antwoord zelfs maar kan beginnen. Dat is waarom dezelfde server lokaal in 150 ms kan antwoorden en vanaf een ander continent in 700 ms, terwijl hij precies hetzelfde werk doet.

Routering doet er ook toe, en dat is minder voorspelbaar dan afstand: verkeer tussen twee netwerken kan een slecht pad nemen dat latency toevoegt voor één regio en verder niemand. Gebruikt u een CDN, dan worden sommige locaties bediend vanuit een nabijgelegen gecachete kopie, terwijl andere de cache missen en de volle reis naar de origin betalen, wat een brede spreiding tussen locaties oplevert voor dezelfde URL.

Meet dus vanaf waar uw gebruikers zijn, niet vanaf waar uw server is, en vergelijk gelijke met gelijke. Een getal zonder locatie erbij is met niets te vergelijken.

Wanneer traag kapot betekent

Sommige traagheid is een waarschuwing eerder dan een prestatieprobleem:

• Een responstijd die gestaag groeit onder belasting betekent dat de server verzadigd is. Het eindigt in time-outs, niet alleen trage pagina's.
• Tijden die precies rond 30 of 60 seconden clusteren zijn time-outs, geen traagheid. Iets stroomopwaarts antwoordt niet en een proxy wacht zijn limiet uit voordat hij opgeeft met een 504.
• Meestal snel met af en toe enorme pieken wijst meestal op een lock, een cronjob, een back-up, of een cache die verloopt waarbij elk verzoek hem tegelijk herbouwt.
• Alleen traag voor ingelogde gebruikers betekent dat de cache het anonieme verkeer draagt en daaronder een werkelijk trage applicatie verbergt.
• Alleen traag vanuit één regio is een netwerk- of CDN-probleem, geen applicatieprobleem, en geen hoeveelheid backend-werk zal dat oplossen.

De dag opmerken waarop het veranderde

Eén meting vertelt u wat er gebeurde voor één verzoek, vanaf één plek, op één moment, en responstijd is precies het soort metriek dat afdrijft in plaats van breekt. Geplande checks meten dezelfde URL doorlopend vanaf dezelfde locaties, houden de geschiedenis bij zodat u de dag kunt aanwijzen waarop het veranderde, en waarschuwen wanneer de tijd een drempel overschrijdt in plaats van wanneer een klant klaagt. HostTracker voert die checks uit vanaf 300+ meetpunten in 158 steden, dus een regionale vertraging is zichtbaar als zodanig. Voer nu een check uit met de HTTP-checktool. Wanneer de server snel is en de pagina nog steeds niet, staat de rest van het antwoord in hoe u de snelheid van een website controleert.