Elk jaar ontdekken winkels hun grenzen op het slechtst mogelijke moment: tijdens een uitverkoop, een TV-vermelding of Black Friday. Een load test stelt je in staat om die grenzen van tevoren te vinden, op jouw voorwaarden.
Deze gids laat zien hoe je een loadtest uitvoert voor een online winkel met k6, een gratis, open-source load testing tool, en hoe je de resultaten kunt interpreteren.
Wat een load test je vertelt
- Hoeveel gelijktijdige shoppers kan uw winkel aan?
- Welke pagina’s vertragen als eerste (meestal zoeken, winkelwagentje en afrekenen)
- Waar de bottleneck is: PHP-werkers, database, zoekmachine, externe API’s
- Of caching werkt onder belasting
- wat voor foutpercentage klanten zouden zien tijdens piek
Soorten tests
| Test | Doel |
|---|---|
| Rooktest | Kleine lading om te controleren of het script werkt |
| Laadtest | Verwachte piekverkeer voor een langdurige periode |
| Stress test | Verhoog totdat het systeem faalt, om de limiet te vinden |
| Spike-test | Plotselinge stijging in verkeer (e-mailcampagne, TV-vermelding) |
| Soaktest | Normale belasting gedurende uren, om geheugenlekken en trage degradatie te vinden |
Voordat je begint
- Test tegen staging of een productie-achtige omgeving met dezelfde hardware en configuratie. Als je productie moet testen, doe dit dan op een rustig moment en informeer je host.
- Informeer uw hostingprovider en CDN, anders kan uw test worden geblokkeerd als een aanval
- Schakel echte betalingen en e-mails uit in de testomgeving
- Sluit testverkeer uit van analytics
- Kennis van je doelgroep: gebruik je analytics om pieksessies, paginaweergaven per minuut en bestellingen per uur te schatten, en voeg vervolgens een veiligheidsmarge toe
Installeer k6
Op Ubuntu/Debian, macOS en Windows kan k6 worden geïnstalleerd vanuit de pakketrepositories van Grafana, met Homebrew (brew install k6) of via Docker. Raadpleeg de officiële k6-documentatie voor uw systeem.
Stap 1: Een eenvoudig browsingscenario
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 },
{ duration: '5m', target: 50 },
{ duration: '2m', target: 0 },
],
thresholds: {
http_req_failed: ['rate<0.01'],
http_req_duration: ['p(95)<1500'],
},
};
const BASE = 'https://staging.example.com';
export default function () {
let res = http.get(`${BASE}/`);
check(res, { 'home 200': (r) => r.status === 200 });
sleep(Math.random() * 3 + 2);
res = http.get(`${BASE}/shoes/trail-running.html`);
check(res, { 'category 200': (r) => r.status === 200 });
sleep(Math.random() * 3 + 2);
res = http.get(`${BASE}/trail-shoe-x200.html`);
check(res, { 'product 200': (r) => r.status === 200 });
sleep(Math.random() * 5 + 3);
}
Voer het uit:
k6 run browse.js
De sleep aanroepen simuleren echte gebruikers die pagina’s lezen. Zonder hen gedragen 50 virtuele gebruikers zich als honderden echte bezoekers.
Stap 2: Voeg realistisch winkelgedrag toe
Echt verkeer is een mix. Een typische verdeling zou kunnen zijn:
- De meeste bezoekers bladeren door de homepage, categorieën en producten
- Een kleinere aandeel zoekt
- Minder toevoegen aan winkelwagentje
- Een kleine aandeel begint de afrekenprocedure
Gebruik aparte scenario’s met verschillende gewichten:
export const options = {
scenarios: {
browsers: { executor: 'ramping-vus', exec: 'browse',
stages: [{ duration: '3m', target: 160 }, { duration: '10m', target: 160 }] },
searchers: { executor: 'ramping-vus', exec: 'search',
stages: [{ duration: '3m', target: 30 }, { duration: '10m', target: 30 }] },
buyers: { executor: 'ramping-vus', exec: 'addToCart',
stages: [{ duration: '3m', target: 10 }, { duration: '10m', target: 10 }] },
},
};
Baseer de splitsing op je eigen analytics-funnel.
Stap 3: Test toevoegen aan winkelwagentje en afrekenen
Winkelwagentje en afrekenen zijn de belangrijkste en minst cachebare onderdelen. Toevoegen aan winkelwagentje vereist meestal een sessiecookie en een formulier sleutel of nonce, die je moet extraheren van de productpagina:
- Magento: de
form_keyvan de pagina of cookie - WooCommerce: voeg toe aan winkelwagentje via
?add-to-cart=PRODUCT_IDof de Store API - Shopify: de AJAX Cart API (
/cart/add.js). Opmerking: Shopify beheert de infrastructuur; controleer de beleidslijnen van Shopify voordat je een Shopify-winkel onderwerpt aan load testing, en richt je in plaats daarvan op je eigen apps en integraties.
k6 houdt automatisch cookies per virtuele gebruiker bij. Gebruik check() om te verifiëren of de winkelwagentje echt het product bevat.
Voor de checkout, test tot aan de betalingsstap met een testbetaalmethode, of simuleer de betalingsprovider op staging. Genereer nooit echte bestellingen tegen echte betalingsproviders.
Stap 4: Monitor de server tijdens de test
De k6-uitvoer toont responstijden en fouten. Je moet ook zien waarom:
- CPU en geheugen per server
- PHP-FPM actieve processen en wachtrij (
pm.status_path) - Database: verbindingen, trage queries, vergrendelingen
- Cache hit ratio (Varnish, CDN, Redis)
- Zoekmachinebelasting (OpenSearch/Elasticsearch)
- Externe API-responstijden (verzending, betaling, belasting)
Een APM-tool zoals New Relic, Tideways of Blackfire maakt het veel gemakkelijker om de bottleneck te vinden.
De resultaten lezen
| Metriek | Waar op te letten |
|---|---|
http_req_duration p(95) |
95% van de verzoeken sneller dan dit. Kijk hoe het groeit met de belasting |
http_req_failed |
Foutpercentage. Alles boven een fractie van een procent heeft aandacht nodig. |
iterations |
Voltooide gebruikersreizen |
| Server CPU / PHP-werkers | Verzadigde werknemers betekenen dat verzoeken in de wachtrij komen. |
Het doorbraakpunt is waar de responstijden scherp stijgen of fouten verschijnen. Je verwachte piek zou goed onder dat punt moeten liggen.
Veelvoorkomende knelpunten gevonden door belastingstests
- Te weinig PHP-FPM-werkers, of te veel voor het beschikbare geheugen
- Volledige pagina-cache werkt niet voor bepaalde pagina’s of parameters
- Langzame databasequery’s op gelaagde navigatie of zoekopdracht
- Sessieopslag op schijf in plaats van Redis (zie gids voor Redis-objectcache)
- Externe API-aanroepen in de checkout (verzendtarieven, adresvalidatie)
- Zware plugins of extensies op winkelwagentjespagina’s
Na het repareren: test opnieuw
Load testing is een cyclus: test, vind knelpunten, los op, test opnieuw. Plan tijd voor ten minste twee of drie rondes voor je piek.
Veelgestelde vragen
Kan ik een loadtest uitvoeren op productie?
Het is mogelijk, maar riskant. Geef de voorkeur aan een stagingomgeving die lijkt op productie. Als je productie test, doe dit dan ’s nachts, begin klein en informeer je host.
Hoeveel virtuele gebruikers heb ik nodig?
Bereken vanuit analytics: piek gelijktijdige sessies, met realistische denktijden, plus een veiligheidsmarge. Virtuele gebruikers met pauzes zijn niet hetzelfde als paginaweergaven per seconde.
Is k6 gratis?
De k6 commandoregeltool is open source. Grafana biedt ook een cloudservice aan voor grotere gedistribueerde tests.
Wilt u een professionele belastingstest?
Ik voer belastingtests uit voor Magento en WooCommerce winkels, vind de knelpunten en los ze op voordat het hoogseizoen begint. Bekijk mijn servers en back-upservice of vraag een belastingtest aan.