Spike testing nadat uw load test is geslaagd: de vijf faalmodi die graduele tests verborgen houden

Een loadtest draait op tien keer het stabiele verkeer. Elke drempelwaarde staat op groen. Aan elke SLO is voldaan. Twee weken later zorgt een vermelding op Product Hunt ervoor dat het verkeer binnen negentig seconden ongeveer verdubbelt ten opzichte van de basislijn. De P99-latentie schiet omhoog van 180 ms naar 14 seconden. Het foutpercentage bereikt 38%. De autoscaler is nog bezig met het opstarten van replica’s terwijl de piek alweer voorbij is.

De loadtest mat hoe het systeem presteert onder hoge belasting. Hij mat niet hoe het systeem presteert tijdens de aanloop naar die belasting. Dat hiaat is waar dit artikel over gaat. De volgende secties bespreken de vijf mechanische redenen waarom productieomgevingen bezwijken, zelfs na een geslaagde loadtest, noemen de metriek die u voor elk punt in de gaten moet houden, en beschrijven het type test dat dit aan het licht brengt.

Volgens het rapport van Splunk en Cisco verliest de gemiddelde onderneming nu ongeveer $15.000 per minuut aan ongeplande uitval, en 57% van de datacenterexploitanten in de Uptime Institute Annual Outage Analysis 2026 zegt dat hun meest recente grote storing meer dan $1 miljoen heeft gekost. De meeste van die storingen beginnen op dezelfde manier: met een piek die de steady-state test nooit heeft gesimuleerd.

Waarom loadtests slagen en de productieomgeving toch uitvalt

Drie mechanische verschillen scheiden een loadtest van een praktijkpiek, en elk verschil verhult stilletjes een type fout.

De opbouwsnelheid (ramp rate) is de eerste. Een loadtest loopt meestal in minuten op, terwijl een flash sale, pushbericht of uitgelichte app in de App Store hetzelfde volume in seconden levert. De HPA, de connection pool en de cachelaag gedragen zich allemaal anders wanneer ze negentig seconden de tijd hebben om te reageren in plaats van negen.

Wat gemeten wordt, is de tweede. Een loadtest rapporteert de steady-state doorvoersnelheid, p95 en het foutpercentage op een plateau. Het zegt niets over het tijdelijke gedrag tijdens de klim, en dat is precies het moment waarop systemen bezwijken.

Wat warm blijft, is de derde. Tegen minuut drie van een geleidelijke opbouw zijn caches gevuld, heeft de JIT de hot paths gecompileerd, heeft de autoscaler al capaciteit toegevoegd en heeft de connection pool zich tot een werkbare grootte genesteld. Een echte piek treft een koud systeem. De loadtest heeft dat pad nooit getest.

Dit is het kader waarop de rest van het artikel rust: een spiketest in softwaretesten is een aanvulling op loadtesten. Loadtesten beantwoorden de vraag: “kunnen we X volhouden?” Spiketesters beantwoorden de vraag: “kunnen we snel genoeg naar X toe?” Beide vragen behoeven antwoorden. De meeste teams stellen alleen de eerste.

De vijf faalwijzen

De onderstaande fouten zijn mechanisch, niet exotisch. Ze komen voor in bijna elke evaluatie na een incident waarbij het team vooraf wel degelijk loadtests heeft uitgevoerd. Elke sectie benoemt het mechanisme, legt uit waarom een geleidelijke opbouw dit verhult, noemt de metriek die het blootlegt en beschrijft de testvorm die het zou hebben opgemerkt.

Vertraging van de autoscaler

Beslissingen van de Horizontal Pod Autoscaler in Kubernetes draaien op aggregatievensters van ongeveer 30 tot 90 seconden, en het toevoegen van nodes door cluster autoscalers kan nog enkele minuten langer duren. Volgens de CNCF Annual Cloud Native Survey 2025 draait 82% van de containergebruikers nu Kubernetes in productie, wat betekent dat de meeste productieomgevingen aan precies deze vertraging blootstaan. Een piek die binnen dat beslissingsvenster arriveert en weer verdwijnt, is al voorbij voordat de autoscaler reageert.

Een loadtest bouwt zo langzaam op dat het schalen bij kan houden, waardoor de curve het gat nooit laat zien. In productie is het gat de storing. De metriek om in de gaten te houden is de pod-ready latentie vanaf het moment dat de CPU- of custom-metriekdrempels worden overschreden, samen met de p99-latentie gedurende de eerste 60 seconden van de piek.

De testvorm die dit aan het licht brengt: van nul naar vijf keer de basislijn in minder dan tien seconden, vasthouden gedurende drie minuten, en observeer het deltaverschil tussen de aankomst van het verkeer en de aankomst van de capaciteit. Als u dat verschil niet ziet, houdt de schaling het per ongeluk bij, en op een dag zal dat niet meer zo zijn.

Cache-storm en Thundering Herd-problematiek

Wanneer een populaire cache-sleutel verloopt en er tegelijkertijd een piek aan verzoeken binnenkomt, wordt elk verzoek een cache-miss en raakt het de brondatabase tegelijkertijd. De CPU raakt verzadigd, de query-latentie explodeert en de cachelaag die de belasting had moeten opvangen, wordt de trigger voor de ineenstorting.

De geleidelijke loadtest warmt elke sleutel op tijdens de opbouw. Het miss-pad wordt nooit onder belasting getest. Een echte piek, vooral een die precies rond een TTL-grens valt of na een deploy die de cache heeft geleegd, treft het koude pad met volle kracht.

Houd de cache-hitratio, de QPS-curve van de brondatabase tijdens de eerste seconden van de piek en de p99 van elk endpoint dat gebruikmaakt van een hot cached key nauwlettend in de gaten.

Testvorm: voer de piek uit direct na het legen van de cache, of configureer de test zo dat er jitter aan de TTL-grenzen wordt toegevoegd, zodat missers halverwege de piek optreden. Een spiketest die wordt uitgevoerd tegen een warme cache bewijst niets nuttigs over de weerstand tegen cache-stormen.

Uitputting van de connection pool

Database- en HTTP-connection pools zijn meestal gedimensioneerd voor het aantal queries per seconde in een stabiele toestand. Wanneer er duizend verzoeken in dezelfde seconde binnenkomen en elk daarvan een verbinding nodig heeft, wordt de wachtrij van de pool de bottleneck, zelfs als de database zelf gezond is.

Bij een geleidelijke opbouw kunnen verbindingen op natuurlijke wijze worden hergebruikt tussen verzoeken door. Bij een piek gebeurt dat niet. Threads blokkeren bij het verkrijgen van een verbinding uit de pool, time-outs stapelen zich op en de applicatie lijkt traag terwijl het werkelijke probleem in de poolconfiguratie zit.

Houd deze drie signalen samen in de gaten:

• Wachttijd van de pool bij p99, niet alleen de verzoeklatentie bij p99
• Aantal pool_acquire_timeout fouten per seconde
• Verhouding tussen actieve en inactieve verbindingen tijdens de piek

De testvorm is een scherpe piek zonder opwarmfase. Als uw testframework een fase “ramp users from 1” heeft, verwijder deze dan. Het hele punt is om de opwarming over te slaan die de loadtest u gratis gaf.

Downstream limieten

Uw service kan schalen. Stripe, Twilio, SendGrid, uw authenticatieprovider en uw geocoding API kunnen dat over het algemeen niet, althans niet op de tijdslijn van uw piek. Wanneer uw verkeer verdubbelt, verdubbelt ook het volume dat u naar elke downstream-afhankelijkheid stuurt, en ergens zal een rate limit een HTTP 429 retourneren. Een naïeve retry-logica verergert het probleem alleen maar.

Dit is de faalwijze die loadtests het vaakst missen omdat de meeste loadtests externe API-aanroepen mocken. De productieomgeving doet dat niet. Een voorbeeld van een geslaagde spiketest die echte afhankelijkheden weglaat, zal slagen terwijl het echte systeem faalt, omdat de zwakste schakel door het ontwerp was uitgesloten.

Metrieken: aantal 429-fouten per afhankelijkheid, retry-pogingen per verzoek en door downstream-problemen veroorzaakte latentie, gescheiden van de latentie van uw eigen service.

Testvorm: neem echte sandbox-endpoints op voor ten minste één scenario en ontwerp de piek zo dat deze een rate-limit venstergrens overschrijdt, aangezien rate limiters resetten op basis van een klok die u niet beheert. Het gedrag bij de grens is vaak slechter dan het gedrag midden in het venster. Dezelfde overlap zien we terug in de bredere catalogus van API performance bottlenecks, waar downstream throttling in de meeste productie-audits naar voren komt.

Backpressure in de wachtrij na een piek

De piek is voorbij, het verkeer keert terug naar normaal en de dashboards kleuren groen. Gebruikers die in de tien minuten daarna arriveren, zien echter nog steeds een kapotte site, omdat de wachtrij die tijdens de piek volliep, nog steeds leegloopt. Consumenten zijn aan het inhalen. Achtergrondtaken lopen 20 minuten achter. De herstelcurve is het eigenlijke incident, en niemand houdt die in de gaten.

Loadtesten meten prestaties tijdens de belasting. Ze houden de instrumentatie bijna nooit lang genoeg draaiende om het herstel vast te leggen. Het systeem was “geslaagd” voor de test, op dezelfde manier als een marathonloper de race “voltooide” door de finishlijn te passeren, ongeacht of hij daarna in elkaar zakte.

Houd de wachtrijdiepte in de gaten nadat de piek is geëindigd, evenals de consumer lag in Kafka of RabbitMQ, en de tijd die nodig is om terug te keren naar de baseline p99.

Testvorm: vasthouden-en-loslaten (hold-and-release). Piek, houd een kort plateau vast, laat vallen naar nul en meet vervolgens nog minstens tien minuten door. De herstelcurve is het resultaat. Als het niet binnen uw SLO-venster terugkeert naar de baseline, hebt u een probleem met tegendruk (backpressure) dat met geen enkele hoeveelheid extra capaciteit opgelost kan worden.

De test ontwerpen die uw incident onderschept

Drie herbruikbare vormen voor piektesten dekken de meeste productiescenario’s, en de keuze daartussen hangt af van wat er is misgegaan, niet van wat er in een leerboek staat.

Twee praktische opmerkingen over parameters. Kies ten eerste de vermenigvuldiger op basis van het incident, niet op basis van een sjabloon. Als de productie 2,3x het normale verkeer zag over 90 seconden en uitviel, test dan 3x over 60 seconden, niet 10x over 10 minuten. De vermenigvuldiger uit een blogpost hoort bij het verkeer van iemand anders. Ten tweede moet de testomgeving de echte autoscaling-configuratie, echte cache-TTL’s en ofwel echte ofwel gesandboxte downstream-afhankelijkheden bevatten. Een stagingomgeving waar HPA niet is geconfigureerd, kan vier van de vijf bovenstaande faalmodi niet reproduceren.

Dit is ook waar interactiepatronen tussen services het probleem vergroten. Dezelfde dynamiek wordt in detail getoond in deze handleiding voor performance-testing van microservices, waarbij elke extra hop een nieuw oppervlak toevoegt voor uitval door pieken.

Piektesten vs. stresstesten

Deze twee worden routinematig als synoniemen behandeld, en dat zouden ze niet moeten zijn.

Piektesten meten de tijdelijke respons op plotselinge veranderingen in de belasting. Korte uitbarstingen, snelle toenames, meting van het herstel. Het beantwoordt de vraag: “wat gebeurt er met gebruikers in de eerste 90 seconden van een onverwachte toename?”

Stresstesten meten aanhoudend gedrag voorbij de capaciteit. De belasting wordt vastgehouden voorbij het breekpunt om te achterhalen waar het systeem faalt en hoe het faalt. Het beantwoordt een andere vraag: “waar ligt het plafond, en wat gebeurt er als we dat bereiken?”

Piek detecteert fouten in reactiesnelheid. Stress detecteert verzadigingsfouten. Hetzelfde systeem kan slagen voor de ene en falen voor de andere, en daarom voeren volwassen teams beide uit, op verschillende schema’s en met verschillende vormen. Hetzelfde principe ligt ten grondslag aan pre-release pressure testing, waarbij de gereedheid voor een lancering met grote inzet wordt gemeten aan de hand van beide vormen tegelijk.

Tools en omgevingspariteit

Tooling is minder belangrijk dan de meeste teams aannemen. k6, JMeter, Gatling en Locust ondersteunen allemaal elke hierboven beschreven vorm. De keuze daartussen hangt meer af van de bekendheid van het team en patronen in CI-integratie dan van pure mogelijkheden.

Wat de resultaten daadwerkelijk verandert, is omgevingspariteit. Een stagingcluster zonder echte HPA-configuratie, echte cache-TTL’s en echte of gesandboxte downstream-afhankelijkheden laat de test slagen terwijl de productie faalt. De meeste teams investeren te veel in de selectie van tools en te weinig in de stagingomgeving die bepaalt of de test enige betekenis heeft. Als u er maar een van de twee kunt repareren, repareer dan de pariteit. Een formeel proces voor performance-testing begint om precies deze reden meestal met een evaluatie van de omgeving voordat er ook maar één test wordt geschreven.

Voorafgaand aan gebeurtenissen en na incidenten

Twee scenario’s rechtvaardigen de kosten van een piektest, en beide betalen zich sneller terug dan de meeste teams verwachten.

Vóór elke gebeurtenis waarbij het verkeer realistisch gezien binnen een minuut vijf keer de baseline zou kunnen bereiken: productlanceringen, betaalde campagnes die live gaan, persberichten, vermeldingen in de App Store, geplande drops. De kosten voor het uitvoeren van de test zijn verwaarloosbaar vergeleken met de kosten van een uitval tijdens een marketingmoment dat elk kwartaal plaatsvindt.

Het tweede scenario is na elk incident waarbij de productie zich anders gedroeg dan staging. Dit is wanneer piektesten zich het snelst terugbetalen, omdat de tijdlijn van het incident precies vertelt welke vorm u moet uitvoeren. De analyse wijst naar de faalmodus. De faalmodus kiest de test.

Als de laatste loadtest slaagde en de laatste lancering niet, dan is dat het gat dat gedicht moet worden. Neem contact met ons op om vanuit de tijdlijn van het incident terug te werken naar de testvorm die het probleem had kunnen detecteren.