Voor veel webshops is de laatste vrijdag van november de belangrijkste dag van het jaar. Dat is precies wat het zo pijnlijk maakt als de site het die dag begeeft. De eigenaar van een webshop in outdoorkleding uit de omgeving van Deventer maakte dat mee: tussen half elf en half één ‘s middags was de shop onbereikbaar, precies tijdens de piek. Wat dat gekost heeft, is niet exact te zeggen, maar het was een flinke hap uit de dag.

Een jaar later verliep dezelfde dag zonder één minuut uitval, bij ruwweg vier keer het normale bezoek. Dit is het verslag van wat er tussen die twee Black Fridays is gebeurd. Geen wondermiddel, wel een reeks nuchtere maatregelen die grotendeels in de weken ervoor zijn genomen. Het is geschreven zodat u het zelf kunt naspelen.

De situatie: wat er het jaar ervoor misging

Na afloop van de eerste, mislukte Black Friday is er een analyse gemaakt op basis van de serverlogs en de foutmeldingen. Er waren drie oorzaken die elkaar versterkten.

Geen paginacache voor bezoekers zonder winkelwagen. Elke productpagina werd voor elke bezoeker opnieuw door PHP opgebouwd, inclusief database-queries. Bij normaal bezoek merkte niemand dat. Bij een veelvoud daarvan liep het aantal PHP-processen tegen de limiet van het hostingpakket aan, waarna nieuwe bezoekers een foutpagina kregen.

Een zoekfunctie zonder rem. De uitgebreide zoekplugin deed per zoekopdracht een zware query over alle producten en varianten. Op de drukste momenten stonden er tientallen van die queries tegelijk in de wachtrij, wat de database vertraagde voor iedereen, ook voor mensen die alleen wilden afrekenen.

Alles tegelijk gepland. De nieuwsbrief ging om 10:00 uit naar de hele lijst, precies op het moment dat het organische verkeer ook al piekte, en er stond nog een geplande voorraadimport op 10:30.

Kortom: het was niet één ding. Dat is het bijna nooit.

De aanpak: zes weken voorbereiding

Vanaf half oktober is er in kleine stappen gewerkt, met steeds een test op een kopie van de site voordat er iets naar de live-omgeving ging.

  1. Een echte paginacache ingericht. Alle pagina’s behalve winkelwagen, afrekenen en mijn-account worden gecachet en vanaf de server geserveerd zonder PHP. Dat alleen al scheelde bij een belastingtest ongeveer een factor tien in het aantal bezoekers dat de server aankon.
  2. Objectcache aangezet. Herhaalde databasevragen worden in het geheugen bewaard. Vooral merkbaar in de beheeromgeving en op de winkelwagenpagina, die niet gecachet mag worden.
  3. De zoekplugin vervangen. Er is overgestapt op een lichtere oplossing met een eigen index. De zoekresultaten werden er ook nog beter van, wat een prettige bijvangst was.
  4. De database opgeruimd. Oude revisies, verlopen transients en een tabel met logregels van drie jaar oud. De database ging van bijna twee gigabyte naar iets meer dan driehonderd megabyte.
  5. Afbeeldingen omgezet naar WebP en lazy loading gecontroleerd. De gemiddelde productpagina werd ruim de helft lichter, wat vooral op mobiel scheelde.
  6. Hosting tijdelijk opgeschaald. Voor de maand november is er een pakket met meer werkgeheugen en meer PHP-workers genomen. Kosten: een paar tientjes. In december weer terug.

Tussendoor is er twee keer een belastingtest gedaan op de staging-omgeving, met een gesimuleerd aantal gelijktijdige bezoekers dat ruim boven de verwachte piek lag. De eerste test liep vast, de tweede niet. Dat is precies waarvoor u zulke tests doet.

De laatste week: het draaiboek

In de week ervoor is alles bevroren. Geen plugin-updates, geen thema-aanpassingen, geen nieuwe functies. De enige toegestane wijzigingen waren prijzen, teksten en producten.

Verder is er een kort draaiboek gemaakt van één A4:

  • Een volledige back-up op donderdagavond, buiten de server, gecontroleerd op grootte en herstelbaarheid.
  • Alle geplande taken verspreid: voorraadimport ‘s nachts, nieuwsbrief om 07:00 in plaats van 10:00, en in twee delen verstuurd.
  • Monitoring op de afrekenpagina, elke minuut, met een WhatsApp-melding.
  • Een tweede melding als er tussen 08:00 en 23:00 negentig minuten geen bestelling binnenkwam.
  • Twee telefoonnummers op het A4: de hosting en de technische contactpersoon.
  • Een vooraf geschreven tekstblok voor op de homepage, voor het geval er toch iets misging.

Dat laatste is klein maar waardevol. Als het misgaat, wilt u niet op dat moment gaan bedenken hoe u het netjes formuleert.

De dag zelf

De piek lag tussen 09:00 en 11:00 en nog eens rond 20:00. Op het drukste moment waren er ongeveer vier keer zoveel gelijktijdige bezoekers als op een gewone drukke dag. De gemiddelde laadtijd van een productpagina bleef onder de anderhalve seconde, tegen ruim vier seconden het jaar ervoor bij minder bezoek.

Er is één ding misgegaan, en dat is leerzaam: rond 20:30 begon de verzendkostenberekening trager te worden, omdat de koppeling met de vervoerder per bestelling een live-aanvraag deed en die dienst zelf onder druk stond. De oplossing was dat de tarieven tijdelijk uit een vaste tabel werden gehaald in plaats van live opgevraagd. Dat kostte tien minuten en was voor klanten niet merkbaar. Wel is het als leerpunt genoteerd: elke externe koppeling in de bestelflow is een afhankelijkheid die u niet in de hand heeft.

Aan het eind van de dag: nul minuten uitval, geen enkele mislukte betaling door een technische oorzaak, en een omzet die ruim boven die van het jaar ervoor lag. Hoeveel daarvan aan de techniek te danken is en hoeveel aan een beter aanbod, valt niet hard te maken. Wat wel vaststaat, is dat er die dag geen twee uur is weggevallen.

De lessen

Vier dingen die de eigenaar er zelf uithaalde, en die voor de meeste webshops gelden:

  1. Snelheidswerk is capaciteitswerk. Een shop die twee keer zo snel is, kan meer dan twee keer zoveel bezoekers aan, omdat elke bezoeker de server korter bezet houdt.
  2. Test met echte belasting, niet met een snelheidsscore. Een goede score bij één bezoeker zegt weinig over wat er gebeurt bij vijfhonderd.
  3. Bevries de week ervoor. De meeste storingen op piekdagen zijn geen capaciteitsproblemen maar wijzigingen die op het verkeerde moment live gingen.
  4. Spreid alles wat u zelf plant. Uw nieuwsbrief, uw imports en uw back-ups horen niet op hetzelfde moment als uw piek.

Voor wie dit soort voorbereiding niet zelf wil draaien: het is precies het werk dat in onderhoud voor een WooCommerce-webshop zit, met als verschil dat het dan het hele jaar door gebeurt in plaats van in een sprint van zes weken. Wie het zelf oppakt, kan de volgorde uit dit artikel gewoon aanhouden.

Tot slot

Een piekdag zonder storing is geen geluk maar een optelsom van saaie maatregelen die weken eerder zijn genomen. Cache, een opgeruimde database, lichtere pagina’s, tijdelijk meer capaciteit, een spreiding van geplande taken en een draaiboek van één A4.

Uw volgende stap: zet in uw agenda een moment zes weken voor uw eigen drukste dag, en begin daar met de belastingtest. Wilt u een concrete voorbereidingslijst, lees dan hoe u uw webshop op Black Friday voorbereidt, en kijk daarna naar wat uw server aan drukte aankan.