Waarom crasht mijn webshop zodra het druk wordt?

Je verstuurt de nieuwsbrief, de eerste klikken komen binnen en een paar minuten later laadt de productpagina niet meer. Het eerste mailtje dat je daarna krijgt, komt van een klant die niet kan afrekenen. Op zo'n moment wil je weten waarom je webshop crasht en hoe je hem zo snel mogelijk terugkrijgt.

Elke minuut uitval kost omzet en zorgt voor onrust bij klanten. Toch zou ik op dat moment geen grotere server bestellen voordat duidelijk is waar het knelpunt zit. Zo'n storing is zelden één los technisch incident. Meestal bezwijkt een keten onder druk: hosting, applicatiecode, database of koppelingen, vaak in combinatie. Extra capaciteit is snel geregeld. Zit de oorzaak in een zware query of een trage koppeling, dan staat bij de volgende actie dezelfde storing weer voor de deur.

Waarom je webshop crasht tijdens een piek

Op een normale dinsdag heeft je server ruimte genoeg. Tijdens een actie zoeken honderden bezoekers tegelijk, laden ze productafbeeldingen, vullen ze hun mandje en rekenen ze af. Al die processen doen op hetzelfde moment een beroep op dezelfde database of dezelfde externe API. Zodra één onderdeel achterloopt, stapelen de wachtrijen zich op. Een capaciteitsmeting op een rustige dag vertelt je daarom weinig over wat er gebeurt als de nieuwsbrief uitgaat.

Gedeelde hosting kan voor een kleine of rustige webshop een prima start zijn. Zodra je omzet afhangt van snelheid, wordt het een beperking. Je deelt capaciteit met andere sites, je hebt weinig invloed op de instellingen en vaak hoor je pas van een probleem als een klant het meldt.

Een VPS of cloudserver is ook niet vanzelf goed ingericht omdat er meer capaciteit in zit. Te weinig geheugen, ongunstige PHP-instellingen of een webserver die te weinig gelijktijdige aanvragen afhandelt, laten ook zo'n server vastlopen. De inrichting moet passen bij je applicatie en bij de momenten waarop de belasting piekt.

Kijk eerst naar database en koppelingen

Als ik bij een storing één plek mocht kiezen om te beginnen, dan is het de database. Voorraad, prijzen, klantgegevens, bestellingen en productvarianten komen daar samen. Een pagina die per bezoek tientallen zware databasequeries uitvoert, houdt het bij drukte niet vol. De database gaat verbindingen weigeren of laat taken eindeloos wachten.

Caching haalt daar veel druk af, mits je bewust kiest wat je cachet. Mijn vuistregel: wat voor iedere bezoeker gelijk is, zoals een categoriepagina, mag in de cache. Voorraad, winkelmandjes en persoonlijke prijzen moeten actueel blijven. Cache je te agressief, dan ziet een klant verkeerde informatie. Cache je te weinig, dan maak je je platform onnodig zwaar.

Daarna kijk ik naar alles wat er in de loop der jaren bij is gekomen. Een extra betaalmethode, een marketingtool of een koppeling met je boekhouding lijkt klein. Toch brengt elke extensie code, databaseverzoeken en afhankelijkheden mee. Op platforms die lang zijn doorontwikkeld, draait vaak een verzameling plugins waarvan niemand precies weet wat ze doen tijdens de checkout of een voorraadupdate.

Maatwerk kan hetzelfde effect hebben als het nooit onder gelijktijdige belasting is getest. Een functie die één productprijs ophaalt, is onschuldig. Een functie die bij elke paginaweergave duizenden prijzen controleert via een externe koppeling, legt je shop plat zodra het druk wordt. Zulke problemen komen vaak boven na een update, terwijl de oorzaak al veel langer in de code zat.

Dan de koppelingen zelf. Betaalproviders, fulfilmentpartijen, ERP- en PIM-systemen, verzenddiensten en e-mailplatforms zitten vaak midden in je orderstroom. Blijft je webshop wachten op een dienst die traag antwoordt, dan lopen processen vast, en in een drukke checkout merk je dat direct. Een voorraadcontrole die voor elke bezoeker synchroon draait, kan vaak ook periodiek en gecontroleerd worden bijgewerkt. Met time-outs, een wachtrij, foutafhandeling en een fallback blijft je webshop verkopen als een externe dienst hapert.

Een 504 zegt niet welk onderdeel wacht

Wie tijdens een storing meteen instellingen gaat aanpassen, maakt het probleem soms groter. Begin met opschrijven: het tijdstip, de foutmelding, welke pagina's geraakt zijn en wat er op dat moment veranderde. Liep er een campagne? Draaide er een import? Is er vlak daarvoor een update of een nieuwe koppeling live gezet? Met die context ben je veel sneller bij de oorzaak.

Volg daarna de keten. Servermonitoring laat zien of CPU, geheugen, schijfruimte of netwerkverkeer tegen een grens aanloopt. In de applicatielogs staan fouten in code, plugins en processen, en database-monitoring toont welke queries traag zijn en welke tabellen geblokkeerd raken. Gaat het mis in de checkout, vraag dan ook de logs van je betaalprovider en je API-koppelingen op.

Een foutcode als 502, 503 of 504 is een aanwijzing, geen diagnose. Een 504 betekent dat een onderdeel te lang wacht. Dat kan een uitgeputte PHP-worker zijn, een trage databasequery of een API die niet reageert. Om dat uit elkaar te halen heb je iemand nodig die infrastructuur en applicatie in samenhang bekijkt.

Een belastingtest met duizend homepagebezoeken zou ik overslaan. Die laat vooral zien dat je homepage snel is. Een bruikbare test doet na wat klanten werkelijk doen: zoeken, filteren, productpagina's openen, inloggen, bestellen en betalen. Juist in die mix zie je waar het gaat haperen.

Neem ook de taken mee die buiten beeld draaien, zoals voorraadimporten, factuurgeneratie, productfeeds en back-ups. Start zo'n taak midden in een verkoopactie, dan eist hij capaciteit op die je checkout nodig heeft. Lang niet elk proces hoeft direct te draaien. Met planning en prioriteit win je hier vaak meer dan met zwaardere hardware.

Een grotere server koopt vooral tijd

Ligt de winkel plat, dan gaat bereikbaarheid voor alles. Extra capaciteit inzetten, een foutieve extensie tijdelijk uitschakelen of zware achtergrondtaken pauzeren is dan verstandig. Behandel het als eerste hulp. Zolang het onderliggende knelpunt blijft bestaan, komt het probleem bij de volgende piek terug.

Slokt één gebrekkige query alle capaciteit op, dan doet hij dat op een grotere server ook, alleen iets later.

Opschalen is wel de juiste stap als je bezoekersaantallen structureel groeien en de toepassing technisch efficiënt werkt. Een drukke B2B-webshop met complexe prijsafspraken stelt andere eisen dan een catalogus met weinig transacties. Dedicated resources, een gescheiden database of een schaalbare architectuur kunnen dan passen, en optimalisatie vervangt zo'n upgrade niet altijd. De volgorde die ik aanhoud: meten, oorzaak vaststellen, verbeteren en daarna gericht capaciteit toevoegen.

Leg vast wie welk onderdeel bewaakt

Staat je hosting bij de ene partij, de ontwikkeling bij een tweede en een integratie bij een derde, dan duurt de analyse vaak te lang. Iedere partij kijkt naar het eigen onderdeel, terwijl je klant alleen een webshop ziet die niet werkt. Schrijf daarom op wie verantwoordelijk is voor hosting, applicatiebeheer, updates, koppelingen en monitoring.

Test wijzigingen in een aparte omgeving voordat ze live gaan, ook als je webshop klein is. Updates, themawijzigingen en nieuwe koppelingen controleer je daar, terwijl de live winkel doorverkoopt. Zorg daarnaast voor automatische back-ups en een herstelprocedure die je kent. Richt je monitoring zo in dat je meer krijgt dan een melding als de website offline is: oplopende responstijden, stijgende foutpercentages en ongebruikelijke belasting horen ook een signaal te geven.

Bij LJPc zitten ontwikkeling, hosting en support onder één dak in Assen. Daardoor kunnen we een storing volgen van de server tot in de code, en dat geeft ruimte om campagnes en groei met meer vertrouwen te plannen.

Staat er een actie of nieuwsbrief op de planning, leg dan het verzendmoment naast de planning van je imports, feeds en back-ups. Schuif alles wat kan wachten naar een rustig uur. Kijk daarna in je monitoring of je een signaal krijgt bij oplopende responstijden. Hoor je pas iets als de site al plat ligt, dan is dat het eerste wat ik zou laten aanpassen.