Uw applicatie werkt perfect met tien gebruikers. Wat gebeurt er op de uitverkoopdag, met tienduizend? Belastingtesten versus stresstesten beschrijven twee verschillende manieren om dit te beantwoorden, en het combineren ervan leidt tot tests die niet bewijzen wat je denkt dat ze doen.

In deze handleiding wordt uitgelegd wat elke test laat zien, de bijbehorende testtypen en hoe u de resultaten kunt lezen. We hebben de onderstaande kleine percentielberekening uitgevoerd op Python 3.13, met gesimuleerde getallen. De k6-scripts zijn illustratieve voorbeelden die we niet hebben uitgevoerd, en de gebruikersaantallen en doelen zijn bedacht, dus vervang ze door uw eigen. Voer deze tests alleen uit op systemen waarvan u de eigenaar bent of waarvoor u toestemming heeft om te testen, aangezien zwaar verkeer op een aanval kan lijken en echte storingen kan veroorzaken.

Het korte antwoord

Bij een belastingstest wordt de vraag gesteld: kunnen we het verkeer dat we verwachten aan, en daarbij onze doelstellingen halen? Een stresstest vraagt ​​zich af: hoeveel kunnen we verdragen voordat we falen, hoe falen we en hoe snel herstellen we?

Denk aan een brug. Een beladingstest rijdt met het verwachte aantal vrachtwagens over de grens en bevestigt dat het in orde is. Een stresstest blijft gewicht toevoegen om erachter te komen wat de limiet is, en of er eerst een waarschuwing wordt gegeven. Gelukkig is software goedkoper om te breken dan een brug.

Belastingtesten versus stresstesten naast elkaar

Wat is belastingtesten?

Met belastingtests wordt het realistische verkeer gesimuleerd dat u verwacht, en wordt gemeten hoe het systeem zich gedraagt. Het heeft een doel nodig om te testen, bijvoorbeeld: “bij 500 gelijktijdige gebruikers eindigt 95% van de betaalverzoeken binnen 800 ms, met minder dan 1% fouten.”

Hier ziet u hoe dat eruit zou kunnen zien als een k6-script. k6-tests zijn geschreven in JavaScript en thresholds zetten uw doelen om in een geslaagd of mislukt resultaat:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

De sleep is belangrijk. Zonder denktijd hamert elke virtuele gebruiker voortdurend op de server, waardoor veel meer verkeer wordt gegenereerd dan hetzelfde aantal echte mensen zou doen.

Wat is stresstesten?

Stresstesten gaan doelbewust verder dan de verwachte niveaus. Je probeert niet te passeren. Je wilt antwoorden op vragen als:

• Op welk niveau beginnen de prestaties uit elkaar te vallen?
• Welk onderdeel faalt als eerste: de database, de applicatieservers of een oproep van derden?
• Mislukt het probleemloos met duidelijke fouten, of crasht het en gaan er gegevens verloren?
• Herstelt het zichzelf als het verkeer afneemt?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Die laatste herstelfase wordt vaak vergeten, en is misschien wel de meest waardevolle. Een systeem dat goed met storingen omgaat, maar nooit herstelt zonder handmatig opnieuw op te starten, betekent nog steeds een storing die iemand midden in de nacht moet verhelpen. Idealiter zou een systeem onder extreme belasting op een gecontroleerde manier zijn werk moeten doen, met duidelijke 503 reacties in plaats van een time-out.

Spike, geniet en andere soorten

Belasting- en stresstests behoren tot een bredere familie van prestatietests:

Soak-tests vangen problemen op die korte tests nooit zien. Een klein geheugenlek kan twintig minuten onschuldig lijken en de service pas na twee dagen wegvallen. Spike-tests zijn geschikt voor evenementen zoals flash-verkopen, waarbij het verkeer niet geleidelijk toeneemt.

Metrieken die er toe doen

Waarom gemiddelden misleiden

Gemiddelden verbergen de langzame verzoeken waar echte mensen over klagen. Om dit te laten zien, hebben we 100 gesimuleerde responstijden gegenereerd, waarvan 95 snel (80 tot 200 ms) en 5 erg langzaam (2,5 tot 4 seconden), en vervolgens de algemene statistieken berekend:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Kijk eens goed naar die cijfers. Het gemiddelde van 302 ms beschrijft niemand. Typische verzoeken duurden ongeveer 150 ms, terwijl de langzame verzoeken meer dan 3 seconden duurden. Zelfs p95 ziet er gezond uit na 199 ms, en alleen p99 onthult het probleem. Een cijfer als p95 betekent dat 95% van de verzoeken zo snel of sneller was.

En één procent van de verzoeken is geen zeldzame gebeurtenis. Als een pagina 50 verzoeken doet, heeft een trage p99 invloed op een groot deel van de paginaweergaven. Stel doelen op de percentielen die voor u belangrijk zijn, en bekijk er meerdere samen.

Gereedschap

Elk van deze kan zowel belastings- als stresstests uitvoeren. Kies degene die past bij de vaardigheden van uw team, in plaats van een lijst met functies na te jagen. Als u er een in uw pijplijn wilt gebruiken, gaat u naar Wat is CI/CD.

Hoe u een toets plant

1. Stel doelen. Gebruik echte analyses om uw piekverkeer te vinden en doelen te definiëren.
2. Kies trajecten. Modelleer realistisch gebruikersgedrag, zoals browsen, zoeken en afrekenen, in realistische proporties. Alleen het raken van de startpagina bewijst weinig.
3. Gebruik een realistische omgeving. Een kleine testserver kan de productie niet voorspellen. Noteer eventuele verschillen.
4. Gegevens voorbereiden. Gebruik realistische volumes, want een zoekopdracht die snel is op 100 rijen kan op 10 miljoen rijen crawlen.
5. Waarschuw mensen. Vertel uw operationele team en eventuele derde partijen, en voer niet per ongeluk een laadtest uit bij een betalingsprovider. Mock externe diensten waar nodig.
6. Begin klein. Voer eerst een kleine rooktest uit om te bevestigen dat uw script werkt.
7. Houd alles in de gaten. Zonder serverstatistieken zul je zien dat de snelheid is vertraagd, maar niet waarom.
8. Herhaal. Voer het na elke oplossing opnieuw uit en houd een basislijn bij om mee te vergelijken.

Het lezen van de resultaten

Databases vormen een veelvoorkomend knelpunt, dus als query’s het probleem vormen, lees dan onze handleiding voor SQL-queryoptimalisatie. Die laatste rij van de tabel is een belangrijke valkuil: controleer altijd ook de gezondheid van de machine die de belasting genereert.

Veel voorkomende fouten

• Gebruikers verwarren met verzoeken. Maak duidelijk of een doel gelijktijdige gebruikers of verzoeken per seconde betekent.
• We laten de bedenktijd achterwege. Dit leidt tot meer bezoekersaantallen en levert misleidende resultaten op.
• Te laat testen. Een week voor de lancering is er geen tijd meer om architectuurproblemen op te lossen.
• Met gebruik van één eindpunt. Echt verkeer combineert lees-, schrijf- en zoekacties.
• Caching verbergt alles. Identieke herhaalde verzoeken testen mogelijk alleen je cache, dus varieer de gegevens.
• Eén keer testen. De prestaties veranderen bij elke release, dus voer regelmatig tests uit.

Tot slot

Voer belastingtests uit om te bevestigen dat u het verwachte verkeer aankan, en stresstests om erachter te komen wat er gebeurt als u dat niet kunt. Begin klein: kies uw belangrijkste gebruikerstraject, stel één duidelijk doel en voer een korte test uit tegen staging met monitoring ingeschakeld. Die eerste run leert je meestal iets, en van daaruit kun je verder bouwen.

Veelgestelde vragen

Blijf leren