Er is een verschil tussen vijfhonderd bezoekers op een dag en vijfhonderd bezoekers in dezelfde minuut. Het eerste merkt uw server nauwelijks. Het tweede is de situatie waarin een website veel bezoekers tegelijk moet bedienen, en dat is precies het moment waarop sites onderuitgaan.
Het vervelende is dat het altijd gebeurt op het gunstigste moment: uw nieuwsbrief is net verstuurd, u zat in een radio-item, of een bekende account deelde uw pagina. In dit artikel leest u wat er dan onder de motorkap gebeurt, waar de eerste barst ontstaat en welke voorbereidingen wel en niet zin hebben.
Wat er in de server gebeurt
Uw hosting handelt verzoeken niet oneindig parallel af. Er is een vast aantal werkers dat tegelijk een pagina kan opbouwen. Bij een instappakket zijn dat er vaak vier tot tien. Elk verzoek bezet zo’n werker vanaf het moment dat het binnenkomt tot het moment dat de pagina klaar is.
Rekent u mee. Duurt het opbouwen van een pagina een halve seconde en heeft u tien werkers, dan kunt u ruwweg twintig pagina’s per seconde uitleveren. Bij vijfhonderd mensen die binnen twintig seconden aankomen, komt u daar net mee weg. Duurt het opbouwen twee seconden, dan zakt uw capaciteit naar vijf pagina’s per seconde en loopt de wachtrij vol. Verzoeken die te lang wachten, krijgen een foutmelding: meestal een 503 of een 504.
Daar zit de belangrijkste les van dit hele onderwerp. De snelheid van één pagina bepaalt hoeveel mensen u tegelijk aankunt. Een site die anderhalve seconde nodig heeft in plaats van een halve, valt drie keer zo snel om. Snelheid en capaciteit zijn hetzelfde probleem.
Waar het knelt als een website veel bezoekers tegelijk krijgt
In de praktijk zien we vier plekken die het begeven, meestal in deze volgorde.
De database. Elke opgebouwde pagina stelt tientallen tot honderden vragen aan de database. Die heeft ook een limiet aan gelijktijdige verbindingen. Zit u daaraan, dan krijgt u de klassieke melding “Error establishing a database connection”, terwijl de server zelf nog prima draait.
Pagina’s die niet uit de cache komen. Uw homepage wordt bij een goede opzet uit een kant-en-klaar bestand geleverd en kost bijna niets. Maar een winkelwagen, een kassapagina, een zoekopdracht en een ingelogd account worden altijd opnieuw opgebouwd. Zit uw piek daar, dan helpt uw cache u niet.
Werk dat achter de schermen meeloopt. Geplande taken, statistiekplugins die elk bezoek wegschrijven en koppelingen die per bestelling een extern systeem aanroepen. Bij normaal verkeer valt dat weg in de ruis; bij een piek vechten ze met uw bezoekers om dezelfde capaciteit.
Externe diensten. Uw eigen server houdt het misschien vol, maar de betaaldienst, de verzendpartij of de koppeling met uw voorraadsysteem knijpt dicht bij te veel gelijktijdige aanvragen. Uw site draait dan, maar niemand kan afrekenen.
Hoe u weet wat u nu aankunt
Gissen heeft geen zin, meten kost een halfuur.
- Kijk in uw hostingpakket hoeveel gelijktijdige processen en databaseverbindingen u heeft. Staat het er niet, vraag het aan de helpdesk. Dit is het getal waar alles op steunt.
- Meet hoe lang de server over een pagina doet. Niet de totale laadtijd in de browser, maar de tijd tot het eerste antwoord. Onder de vierhonderd milliseconden is goed.
- Doe een belastingstest op een rustig moment. Er zijn diensten die tegen een klein bedrag vijftig tot tweehonderd gelijktijdige bezoekers simuleren. Test de route die er werkelijk toe doet: productpagina, winkelwagen, kassa, en niet alleen de homepage.
- Kijk terug naar uw vorige piek. Heeft u statistieken van de vorige nieuwsbrief of actie, dan weet u hoeveel mensen er in het eerste kwartier binnenkwamen. Dat is een realistischer getal dan elke schatting.
Een indicatie uit de praktijk: van een nieuwsbrief aan tienduizend adressen wordt ongeveer een vijfde geopend, en daarvan klikt een klein deel door. De helft van die klikken komt binnen in het eerste halfuur. U komt dan al snel op enkele honderden bezoekers in een kort tijdvak.
Wat u kunt doen, van goedkoop naar duur
- Zet paginacaching goed aan en controleer of hij ook echt aanslaat. Dit is verreweg de grootste winst en kost niets. Test met een lege browser of u een cachetreffer krijgt.
- Zet een CDN voor uw afbeeldingen en scripts. Dat haalt het grootste deel van de verzoeken bij uw server weg, ook als de pagina zelf nog door uw server komt.
- Ruim op wat per bezoek meeloopt. Statistieken naar een externe dienst, chatvensters die permanent verbinding zoeken en tellers die zichzelf verversen: uitzetten of beperken.
- Plan zwaar werk buiten uw piek. Productimports, back-ups en synchronisaties horen niet om negen uur ‘s ochtends te draaien als uw nieuwsbrief dan uitgaat.
- Zet uw pakket tijdelijk groter. Bij veel hosters kunt u voor één maand opschalen. Voor een geplande actie is dat vaak de goedkoopste verzekering die er is.
- Verspreid het verzenden. Stuur uw nieuwsbrief in blokken van tweeduizend met tien minuten ertussen. Dezelfde bezoekers, half zoveel piek.
Wat meestal geen zin heeft: een zwaardere server huren terwijl uw pagina’s traag blijven, of een extra beveiligingsplugin die “bescherming tegen overbelasting” belooft. Die laatste voegt zelf werk toe aan elk verzoek. Voor het echt afvangen van een aanval heeft u een dienst nodig die vóór uw server zit, en dat is iets anders dan een piek van echte bezoekers.
Voorbereiden op een geplande piek
Weet u wanneer de drukte komt, dan is de voorbereiding vrij mechanisch. Draai een week van tevoren een belastingstest. Zorg dat u een verse back-up heeft en dat u weet hoe u die terugzet. Zet uptime-bewaking aan die niet alleen de homepage bekijkt maar ook de kassa. Spreek af wie er tijdens het moment bereikbaar is en met welk telefoonnummer van de hosting. En hou een simpele terugvalpagina achter de hand voor het geval het toch misgaat.
Voor webshops rond een actiedag is dit een vast draaiboek geworden. Wat daar allemaal in hoort staat beschreven in het artikel over servercapaciteit bij drukte in een webshop, inclusief de afspraken die u vooraf met uw hoster maakt.
Wilt u de meting en de opschaling niet zelf doen, dan hoort dat werk bij het klaarmaken van een site voor piekverkeer. Bij WebMaintor is een testrun voor een aangekondigde actie een vast onderdeel, juist omdat een piek zich zelden aan uw schatting houdt.
Concrete volgende stap: zoek op hoeveel gelijktijdige processen uw hostingpakket toestaat en meet de servertijd van uw drukste pagina. Die twee getallen samen zeggen binnen tien minuten of uw volgende actie goed gaat of dat u eerst iets moet regelen. Voor de meetkant helpt het overzicht van meettools u op weg.
