De vervelendste storingen komen zelden van een aanval. Ze komen van succes. Een website plat door bezoekerspiek is bijna altijd het gevolg van iets wat u zelf in gang heeft gezet: een mailing, een advertentie die aanslaat, een item in het regionale nieuws.
Deze case beschrijft wat er gebeurde bij een leverancier van tuinmeubelen die op een donderdagochtend om tien uur een aanbieding rondstuurde. Alle namen zijn weggelaten; de cijfers komen uit de logbestanden en de bewakingsdienst.
De tijdlijn van acht minuten
De mailing ging naar ongeveer achtduizend adressen, in één keer verstuurd.
- 10:00 Verzending gestart. Binnen twee minuten was alles de deur uit.
- 10:02 De eerste bezoekers komen binnen. Ongeveer honderdvijftig mensen in de eerste minuut.
- 10:04 De servertijd loopt op van 400 milliseconden naar ruim drie seconden. Nog niet stuk, wel merkbaar traag.
- 10:06 De eerste 503-meldingen. Ongeveer een op de vijf bezoekers krijgt een foutpagina.
- 10:08 De site is voor vrijwel iedereen onbereikbaar. De bewakingsdienst meldt de eerste uitval per sms.
- 10:25 Na een herstart door de hoster komt de site terug, maar hij valt binnen vier minuten opnieuw om.
- 11:10 Stabiel na het uitzetten van twee plugins en het opschalen van het pakket.
Van de achtduizend ontvangers hadden er in dat uur ongeveer elfhonderd geklikt. Van hen kreeg naar schatting de helft een foutmelding of een pagina die niet doorlaadde. De aanbieding liep drie dagen; de eerste dag leverde ongeveer een derde op van wat vergelijkbare eerdere acties opleverden.
Waarom de site plat door bezoekerspiek ging
Achteraf waren er drie oorzaken, en geen daarvan was op zichzelf ernstig.
De landingspagina zat niet in de cache. De pagina was die ochtend gemaakt en de link bevatte een campagneparameter. Die parameter zorgde ervoor dat de cacheplugin elke bezoeker als uniek zag en de pagina telkens opnieuw opbouwde. Elfhonderd bezoekers betekende elfhonderd volledige opbouwrondes in plaats van één.
Er stond een bezoekersstatistiekplugin aan die elk bezoek in de eigen database wegschreef. Per bezoek waren dat vier schrijfacties. Bij een piek is schrijven naar de database precies wat u niet wilt, omdat het de tabel kort op slot zet voor de rest.
Het hostingpakket stond tien gelijktijdige processen toe. Bij een pagina die twee seconden kostte, was de rekenkundige bovengrens vijf pagina’s per seconde. Er kwamen er in de piek ruim twintig per seconde binnen.
Elk van die drie was los op te lossen. Samen zorgden ze ervoor dat de site precies op het duurste moment onbereikbaar was.
Wat er die ochtend is gedaan
- De campagneparameter laten negeren door de cache. Vrijwel elke cacheplugin heeft een lijst met parameters die genegeerd mogen worden. Dit was de grootste ingreep en kostte vijf minuten.
- De statistiekplugin uitgezet. De cijfers liepen ook al via een externe dienst, dus er ging niets verloren.
- Het hostingpakket tijdelijk opgeschaald naar meer geheugen en meer gelijktijdige processen, voor die maand.
- Een chatvenster tijdelijk uitgezet dat op elke pagina verbinding zocht.
- Gecontroleerd of de bestelroute nog werkte, want de winkelwagen en de kassa komen nooit uit de cache en die kregen nu alle ruimte.
Na deze vier ingrepen zakte de servertijd naar 300 milliseconden bij hetzelfde verkeer. De rest van de week hield de site het zonder problemen, ook toen er een herinneringsmail uitging.
Wat er anders had gemoeten
Het pijnlijke aan deze case is dat alles vooraf te voorzien was. Vier dingen hadden het verschil gemaakt.
De landingspagina testen met de echte campagnelink. Niet de pagina zelf openen, maar de link uit de mail plakken en kijken of u een cachetreffer krijgt. Dat is een controle van dertig seconden.
Verzenden in blokken. Achtduizend adressen in vier blokken van tweeduizend, met een kwartier ertussen, geeft precies dezelfde bezoekers en een kwart van de piek. Elk mailpakket kan dit; het heet meestal gefaseerd verzenden.
Vooraf een belastingstest. Voor een paar tientjes simuleert u tweehonderd gelijktijdige bezoekers op de landingspagina. Dan had de cachemisser er meteen uit gerold.
Weten wie er bereikbaar is. Er ging twintig minuten verloren met het zoeken naar het juiste telefoonnummer van de hoster en de inloggegevens van het hostingpaneel.
Een vast draaiboek voor dit soort momenten scheelt meer dan welke technische ingreep ook. Hoe zo’n voorbereiding eruitziet voor een drukke actiedag, staat in de voorbereiding op een drukke actiedag.
De rekensom achteraf
De directe kosten waren beperkt: een middag werk en een opgeschaald pakket. De schade zat in de gemiste omzet van de eerste dag en in het feit dat een deel van de ontvangers een foutpagina zag en niet terugkwam. Dat laatste is niet te meten, maar wel te vermoeden: een tweede klik komt zelden.
De structurele oplossing is achteraf ingevoerd. De cacheconfiguratie is nagekeken op alle parameters die marketingtools toevoegen, er is bewaking ingesteld die niet alleen de homepage maar ook de bestelroute controleert, en er staat nu een vaste afspraak: voor elke mailing aan meer dan duizend adressen wordt de landingspagina getest en wordt gefaseerd verzonden.
Dat soort afspraken is het echte werk achter het weerbaar maken van een site tegen piekverkeer. Bij WebMaintor loopt zo’n controle mee met de aangekondigde acties van klanten, juist omdat de oorzaak bijna nooit technisch ingewikkeld is maar wel altijd op het slechtst denkbare moment toeslaat.
Wat u hier vandaag mee kunt
Stuurt u nieuwsbrieven, dan kunt u binnen een kwartier controleren of u hetzelfde risico loopt. Neem de laatste link die u heeft verstuurd, plak hem in een privévenster en kijk of de pagina uit de cache komt. Kijk daarna in uw mailpakket of gefaseerd verzenden aanstaat. En zoek op hoeveel gelijktijdige processen uw hosting toestaat.
Wilt u het breder aanpakken, dan geeft bewaking die verder kijkt dan de homepage u de vroege waarschuwing die in deze case ontbrak. De sms kwam nu pas toen de site al helemaal weg was, terwijl de eerste tekenen zes minuten eerder zichtbaar waren.
