Waarom gemiddelden liegen over latentie
Stel je een API voor die 99 verzoeken beantwoordt in 100 ms en één verzoek in 10 seconden. De gemiddelde responstijd is ongeveer 199 ms — een getal dat precies geen van de honderd verzoeken beschrijft. De 99 snelle waren twee keer zo snel als het gemiddelde suggereert; het trage was vijftig keer erger. Dit is geen gekunsteld voorbeeld: echte latentieverdelingen zijn sterk scheef, met een lange staart van trage verzoeken door garbage-collection-pauzes, koude caches, lock-contention en overbelaste afhankelijkheden.
Gemiddelden verbergen die staart per definitie — ze smeren de uitschieters uit over alle snelle verzoeken tot alles er prima uitziet. Een latentiegrafiek op basis van gemiddelden kan perfect vlak blijven terwijl een groeiend deel van je gebruikers naar timeouts staart. Daarom vervangt (of vult) elke serieuze monitoringpraktijk het gemiddelde aan met percentielen, die een veel eerlijkere vraag beantwoorden: "hoe traag is het voor de X% minst fortuinlijke verzoeken?"
Wat p50, p95 en p99 werkelijk betekenen
Een percentiel is een simpel idee: sorteer alle responstijden van snelst naar traagst en lees de waarde op een bepaalde positie af. p50 (de mediaan) is de middelste waarde — de helft van je verzoeken was sneller, de helft trager. Het beschrijft de typische ervaring en is veel robuuster dan het gemiddelde, omdat een handvol extreme uitschieters het niet kan verschuiven.
p95 is de waarde waaronder 95% van de verzoeken valt — anders gezegd: 1 op de 20 verzoeken is trager. Het vangt de ervaring van je pechvogels die niet zeldzaam zijn. p99 markeert de traagste 1% — 1 op de 100 verzoeken. Dat klinkt verwaarloosbaar tot je rekent: bij een miljoen verzoeken per dag beschrijft p99 de ervaring van 10.000 verzoeken, elke dag opnieuw.
Een gezonde lezing van het trio: p50 vertelt je hoe je API aanvoelt, p95 waar je gebruikers over klagen, en p99 wat je systemen voor je verbergen. De kloof ertussen telt net zo zwaar als de waarden: een p50 van 100 ms met een p99 van 150 ms is een strakke, voorspelbare dienst; een p50 van 100 ms met een p99 van 4 seconden is een tijdbom.
Waarom staartlatentie je beste klanten het hardst raakt
De contra-intuïtieve eigenschap van staartlatentie is dat ze zich niet gelijkmatig verdeelt — ze concentreert zich op je meest actieve gebruikers. Een gebruiker die één verzoek doet heeft 1% kans om je p99 te raken. Een gebruiker wiens pagina-load uitwaaiert naar 40 API-aanroepen heeft 33% kans dat er minstens één in de traagste 1% belandt. En omdat de pagina slechts zo snel is als de traagste aanroep, ervaren je zwaarste gebruikers — de dashboards, de integraties, de power-klanten — je p99-latentie routinematig, niet uitzonderlijk.
Dit fan-out-effect is waarom grote engineeringorganisaties geobsedeerd zijn door de staart. In microservice-architecturen stapelt het probleem zich op: als service A service B aanroept, die service C aanroept, blokkeert één trage sprong de hele keten, houdt een worker-thread gegijzeld en kan onder belasting uitgroeien tot een cascade van vertragingen in services die zelf perfect gezond waren. Staartlatentie is geen cosmetische metriek — het is de vroege indicator van de verzadigingsproblemen die later storingen worden.
Op welk percentiel moet je alerteren?
Alerteren op het gemiddelde is erger dan nutteloos — het schept vals vertrouwen. Maar alerteren op het verkeerde percentiel schept ruis. Een praktisch schema:
Alerteer op p95 of p99 voor gebruikersgerichte endpoints. Stel de drempel in op basis van je eigen baseline, niet op basis van folklore: meet een normale week en alerteer wanneer het percentiel duurzaam boven pakweg 2–3× zijn baseline uitkomt. Een korte p99-piek tijdens een deployment is normaal; een p99 die tien minuten verhoogd blijft is een echte degradatie. Volg p50 op drift, niet voor alerts. Een langzaam stijgende mediaan is de signatuur van groeiende datasets, ontbrekende indexen of sluipend groeiende payloads — bekijk hem wekelijks in plaats van erop te pagen. Volg de p50/p99-kloof. Een groeiende kloof bij een stabiele mediaan betekent dat de staart als eerste degradeert — het klassieke vroege signaal van een overbelaste afhankelijkheid of connection pool.
En meet waar het telt: percentielen berekend uit je serverlogs missen DNS-, TLS- en netwerktijd volledig. Externe synthetische checks vanuit meerdere regio's meten de latentie die je clients werkelijk ervaren — het getal waarop je gebruikers je beoordelen.
Veelvoorkomende percentielvalkuilen
Drie fouten duiken op in bijna elk latentiedashboard. Percentielen middelen: het gemiddelde van vijf p99-minuutwaarden is niet de p99 van het vijfminutenvenster — percentielen laten zich niet samenstellen. Bereken bij aggregatie over tijdvensters of regio's het percentiel over de samengevoegde data (of gebruik een mergebare sketch), nooit een gemiddelde van percentielen. Steekproefgrootte negeren: een p99 berekend uit 50 verzoeken is in wezen één ongelukkig verzoek vermomd als trend; geef endpoints met weinig verkeer ruimere vensters voordat je hun staart vertrouwt. Percentielen vergelijken over verschillende mixen: een p95 die "verbeterde" na een verkeersdaling weerspiegelt misschien alleen dat de zware queries wegvielen — segmenteer per endpoint en verzoektype voordat je juicht.
Niets hiervan vereist geavanceerde tooling — het vereist continu meten, van buitenaf, met drempels per monitor. Een latentiedrempel op een synthetische check is de simpelste eerlijke implementatie: elke check haalde je latentiebudget of niet, en een reeks mislukkingen is een degradatie waarvan je hoort terwijl het nog een prestatieprobleem is in plaats van een storing.
