Je webshop overleeft de rustige weken van oktober op een hostingpakket dat is gemaakt voor normaal verkeer. Black Friday vraagt geen toestemming voordat het dat verkeer in één uur tijd vertien- of vertwintigvoudigt. Load testing vóór november laat zien waar je stack het begeeft: de afrekenpagina, de database, de imageserver of het hostingpakket zelf. Sla je dit over, dan ontdek je het live, recht voor de neus van betalende klanten, op de dag dat een trage pagina het meeste geld kost. Dit artikel behandelt welke tools echt werken, wat ze kosten, in welke volgorde je moet testen en waar WordPress-sites meestal als eerste falen.
Wat Black Friday-verkeer echt met een site doet
Op een normale dinsdag komen er mondjesmaat bezoekers die rondkijken, één item toevoegen en weer vertrekken. Black Friday stuurt een menigte die op dezelfde vijf productpagina's belandt, slechts minuten nadat je kortingsmail de deur uit is gegaan. De server behandelt elk bezoek als een nieuw verzoek: een database-query, een berekening van het winkelmandje, een sessie-schrijfactie. Elke laag van de stack – de webserver, PHP, de database, de payment gateway – heeft een plafond.
Wanneer de menigte dat plafond overschrijdt, worden pagina's traag en treedt er een time-out op bij het afrekenen. Sommige van die bezoekers vertrekken zonder iets te kopen, en ze komen zelden terug om het later opnieuw te proberen. Load testing vindt het plafond in oktober, terwijl er nog tijd is om het te verhogen, in plaats van in november, wanneer de enige optie is om het in real-time te zien falen.
Load testing-tools en wat ze daadwerkelijk kosten
Drie tools komen telkens weer naar voren voor deze klus: Apache JMeter, k6 en Gatling. JMeter is gratis en nog steeds het standaardantwoord in veel enterprise QA-teams, maar om het goed te laten werken heb je een omgeving nodig die dicht genoeg bij de productieomgeving ligt, load generators die niet iemands laptop zijn en een rekening die meegroeit met het verkeer dat je simuleert.
k6, de load testing-engine van Grafana, lost een deel van dat probleem op. De k6-engine is volledig open source onder de AGPL-3.0-licentie en gratis voor onbeperkt lokaal gebruik, dus je kunt een willekeurig aantal virtuele gebruikers draaien op je eigen hardware zonder kosten. Een goed uitgeruste machine kan meestal tienduizenden virtuele gebruikers tegelijk aan, wat voor de meeste onafhankelijke webshops voldoende is.
De kosten worden pas zichtbaar wanneer je moet schalen of tests vanaf meerdere locaties wilt uitvoeren. Grafana Cloud rekent voor k6 $0.150 per virtueel-gebruikersuur na een gratis maandelijkse tier van 500 uur. Neem een gemiddelde test: 500 virtuele gebruikers gedurende 30 minuten, twee keer per week uitgevoerd. Die run is 250 virtuele-gebruikersuren, en de maand komt in totaal op 2,000 VUh. Als je de cijfers naast elkaar legt, kom je bij Grafana Cloud k6 Pro uit op ongeveer $244 per maand, Artillery Cloud's Team-abonnement rekent een vast bedrag van $199 ongeacht het verbruik, en het Enterprise Team-abonnement van Gatling komt neer op ongeveer $413 per maand, hoewel het Team-abonnement van Gatling slechts 5 uur testen per maand toestaat.
Schaal de test op naar iets dat dichter bij een echte Black Friday-repetitie ligt, zeg 10,000 virtuele gebruikers voor twee uur, en de prijs stijgt mee. Grafana Cloud k6 staat genoteerd op ongeveer $0.15 per VU-uur in de Pro-tier, wat neerkomt op ongeveer $3,000 voor 20,000 VU-uren. Die ene repetitie kan meer kosten dan een maand hosting, en dat is de reden dat de meeste winkels vóór november één keer serieus testen in plaats van elke week.
Wat moet je als eerste testen en in welke volgorde?
Begin met het afrekenproces, niet de homepage. Een homepage die traag laadt is irritant; een afrekenpagina die niet werkt zorgt direct voor omzetverlies, dus die verdient de eerste testrun. Simuleer het exacte pad dat een koper aflegt: productpagina, toevoegen aan winkelwagen, adresformulier, betalingsstap, bevestigingspagina.
Test de payment gateway afzonderlijk en in de sandbox-modus voordat je deze combineert met de rest van het proces. Betalingsproviders limiteren sandbox-verzoeken veel agressiever dan live verkeer, en een load test die de sandbox overspoelt kan die limiet triggeren en valse foutmeldingen produceren die niets te maken hebben met je eigen server. Voer de volledige gecombineerde test twee tot drie weken vóór Black Friday uit, niet in de week zelf, zodat er tijd is om de gevonden problemen te herstellen en de test opnieuw uit te voeren.
Voer het gesimuleerde verkeer snel op in plaats van geleidelijk. Echt Black Friday-verkeer komt in een vlaag, getriggerd door het versturen van een e-mail of een social media-post, niet door een langzame klim in een uur tijd. Een test die te voorzichtig opbouwt verbergt precies het type fout dat je probeert op te sporen.
Waar WordPress-sites daadwerkelijk kapotgaan
De meeste WordPress-fouten zijn terug te voeren op drie limieten, en geen van alle komen ze naar boven totdat de verkeerspiek toeslaat. PHP-FPM, de procesmanager die PHP op de meeste hostingpakketten draait, beperkt het aantal gelijktijdige verzoeken dat het tegelijk kan verwerken. Budget shared hosting en kleine VPS-pakketten zetten die limiet vaak op een enkel cijfer, wat betekent dat de tiende bezoeker die op dezelfde seconde de site bezoekt simpelweg moet wachten of een time-out krijgt.
De database vertelt een soortgelijk verhaal. MySQL en MariaDB beperken beide het aantal open verbindingen, en een WordPress-installatie met veel plugins kan die limiet al bij normaal verkeer bereiken, nog voordat er één bezoeker via een kortingsactie binnenkomt. Caching-plugins en CDN's helpen enorm, maar alleen voor pagina's die ze kunnen cachen. Een actiebanner met een live countdown-timer, een voorraad-teller op een productpagina of een gepersonaliseerde "nog X items op voorraad"-melding kunnen een pagina dwingen terug te vallen naar de ongecachte modus met volledige database-queries op het exacte moment dat het verkeer piekt.
Wat eerst aanpakken en wat kan wachten
Herstel het afreken- en betalingsproces als eerste. Dat is de stap waar een fout direct geld kost, en het is ook de stap waar de meeste load tests als eerste problemen aan het licht brengen. Verhoog daarna de worker-limieten van PHP-FPM en de limieten voor databaseverbindingen, aangezien dit meestal een configuratieaanpassing van één regel is in plaats van een migratie.
Dynamische elementen zoals live voorraad-tellers en countdown-timers kunnen wachten, of worden voor de actieperiode vervangen door een eenvoudigere, gecachte versie. Een simpele "bijna uitverkocht"-badge die elke paar minuten ververst, kost veel minder servercapaciteit dan een live teller, en klanten merken het verschil zelden. Voer in oktober één echte load test uit, herstel wat er gevonden wordt en voer de test twee weken later opnieuw uit om te bevestigen dat de oplossing werkt.
