Piekverkeer opvangen: Black Friday-proof worden

Tijdens Black Friday 2024 zorgden AI-chatbots voor een stijging van 1.800 procent in het verkeer naar retailwebsites. Tegelijk genereerde Cyber Monday 13,3 miljard dollar aan online omzet in één dag. De winnaars waren de webshops die dit aankonten. De verliezers zaten met een offline website op het moment dat het er toe deed.

Piekverkeer is voor veel e-commercebedrijven het grootste technische risico van het jaar. Niet omdat de technologie het niet aankan, maar omdat de voorbereiding ontbreekt. Dit artikel gaat over die voorbereiding: wat je moet regelen, testen en monitoren voor, tijdens en na een piekmoment.

Waarom webshops uitvallen bij piekverkeer

De meeste crashes tijdens Black Friday of andere piekmomenten hebben dezelfde oorzaak: de infrastructuur is gebouwd voor gemiddeld verkeer, niet voor de piek. Die piek kan 5 tot 20 keer zo hoog zijn als een normale dag.

Veelvoorkomende faalpatronen:

• Database overbelasting: bij hoge concurrency lopen databaseverbindingen vol. Queries die normaal 50 ms duren, nemen opeens 2 seconden. De rest van de keten loopt vast.
• PHP-worker uitputting: elke actieve webshop-request houdt een PHP-worker bezet. Als alle workers vol zijn, wachten nieuwe bezoekers in de queue of krijgen ze direct een foutmelding.
• Memory exhaustion: bij hoog gelijktijdig gebruik groeit het geheugengebruik per server. Zonder limiet legt dit de server plat. Met een te strak limiet worden processen afgekapt.
• Third-party bottlenecks: betaalproviders, tracking-scripts, chat-widgets. Als één externe dienst traag is of uitvalt, blokkeert dat de paginalaad van de hele shop.
• Sessie-storm: tienduizenden nieuwe sessies worden tegelijk aangemaakt. Als sessies in bestanden worden opgeslagen in plaats van Redis, loopt de I/O-wachtrij vol.

De basis op orde: wat moet kloppen voor het piekseizoen

Voor je nadenkt over auto-scaling en load testing, zijn er basismaatregelen die altijd op orde moeten zijn:

Redis voor sessies en object cache. Bestands-gebaseerde sessieopslag en directe databasequeries bij elke request zijn de twee meest impactvolle knelpunten. Beide los je op met Redis. Dit is geen optimalisatie, het is een vereiste.

Full-page caching voor categorieën en productpagina's. Op piekmomenten wil je dat zo min mogelijk requests de PHP-stack bereiken. Productpagina's veranderen niet bij elke request. Cache ze. Een goed geconfigureerde Varnish-setup kan 90 procent of meer van het paginaverkeer afvangen voor de webserver.

Databaseconnections pooling. Tools als PgBouncer (PostgreSQL) of ProxySQL (MySQL) voorkomen dat honderden gelijktijdige applicatieprocessen elk een eigen databaseverbinding openen. Een gepoold systeem hergebruikt bestaande verbindingen efficiënt.

Afbeeldingen geoptimaliseerd en extern geserveerd. Grote afbeeldingen die direct van de webserver komen zijn een rem op performance en bandbreedte. Gebruik WebP-formaat, comprimeer bij upload en serveer via een CDN.

Load testing: testen voor het te laat is

Een load test simuleert hoge aantallen gelijktijdige bezoekers om te ontdekken waar de infrastructuur het eerst bezwijkt. Dit doe je ruim voor het piekmoment, zodat je problemen kunt oplossen.

De meestgebruikte tools:

• k6: moderne open-source load testing tool met JavaScript-scripts. Goed leesbare output, integreert goed met CI/CD-pipelines.
• Locust: Python-gebaseerd, flexibel. Geschikt voor complexe scenario's met inloggen, zoeken en aankopen.
• Apache JMeter: de traditionele keuze, uitgebreid maar complexer te configureren.

Test altijd met realistische scenario's. Een load test die alleen de homepage bevraagt is niet representatief. Simuleer een mix van: productpagina's, categorieoverzichten, zoekacties, winkelwagen-interacties en checkouts. Gebruik een mix van ingelogde en niet-ingelogde gebruikers.

Test op minimaal drie keer je verwacht piekniveau. Als je 5.000 gelijktijdige bezoekers verwacht op Black Friday, test dan op 15.000. Pieken zijn zelden precies wat je plant.

Horizontaal schalen voor piekopvang

Als de load test aantoont dat één server het niet aankan, zijn er twee opties: verticaal schalen (grotere server) of horizontaal schalen (meer servers). Voor piekopvang is horizontaal schalen flexibeler: je schakelt servers bij tijdens de piek en schakelt ze erna af om kosten te besparen.

In cloud-omgevingen kun je auto-scaling configureren op basis van CPU-gebruik of inkomende requests. Let op: een nieuwe server opstarten duurt 1 tot 3 minuten. Bij een plotselinge piek (viral effect, openingstijd van een sale) is dat te laat. Zorg dat je de capaciteit al vóór de piek hebt bijgeschakeld.

Een hybride aanpak werkt het best: een vaste basiscapaciteit die je normale verkeer aankan, aangevuld met gereserveerde cloud-capaciteit die je handmatig of automatisch activeert voor pieken.

Monitoring tijdens de piek

Tijdens een piekmoment wil je real-time zicht op wat er gebeurt. Niet pas nadat bezoekers klagen of de site plat is. Stel dashboards en alerts in voor:

• Response-tijden per endpoint (dashboard en productpagina's zijn de meest kritieke)
• Server CPU- en geheugengebruik
• Aantal actieve PHP-workers versus beschikbare capaciteit
• Foutpercentage (HTTP 500s, timeouts)
• Redis en databaseverbindingen in gebruik
• CDN cache-hitpercentage (een laag percentage betekent te veel verkeer bereikt de originele server)

Stel drempelwaarden in die je waarschuwen voordat het mis gaat. Als CPU boven de 70 procent komt, is dat een signaal om actie te ondernemen. Wachten tot 95 procent is te laat.

De menselijke factor

Technologie kan heel wat aan. Wat vaak ontbreekt, is een helder protocol voor als er toch iets mis gaat. Stel op voorhand vast:

• Wie heeft toegang tot de servers en kan direct ingrijpen?
• Wat is het beslissingspunt om extra capaciteit bij te schakelen?
• Hoe communiceer je met klanten als de site traag of onbereikbaar is?
• Wat is de procedure als een deployment teruggedraaid moet worden?

Tijdens een piek is er geen tijd om dit uit te zoeken. Dat regelt in de weken ervoor.

Conclusie

Black Friday-proof zijn is geen technisch wonder. Het is een combinatie van basishygiëne (caching, Redis, CDN), proactieve capaciteitsplanning, load testen en goede monitoring. De meeste webshops die uitvallen bij piekverkeer hadden het kunnen voorkomen met een grondige voorbereiding van vier tot zes weken.

Begin vroeg. Test hard. Monitor alles. En zorg dat er iemand beschikbaar is op de dag zelf.

Klaar voor piekverkeer? Bekijk onze e-commerce hosting of high-traffic oplossingen.