Een website kan op een gewone werkdag snel reageren en tijdens een campagne toch vastlopen. Met loadtesten onderzoek je hoe de site zich gedraagt bij veel gelijktijdige bezoekers, waar de capaciteit ophoudt en welke metingen je helpen de oorzaak te vinden.

Wat een loadtest meet aan een website

Een loadtest bootst bezoek na om te meten hoe een website presteert wanneer meerdere mensen tegelijk pagina’s bekijken, zoeken, inloggen of afrekenen. De test laat zien hoe responstijden, foutpercentages en serverbelasting veranderen naarmate de belasting toeneemt. Dat is iets anders dan alleen controleren of een pagina snel laadt voor één bezoeker: gedeelde onderdelen, zoals databases en externe koppelingen, kunnen pas onder gelijktijdig gebruik een knelpunt worden.

Loadtesten worden vaak verward met andere prestatietests. Een belastingtest onderzoekt gedrag bij een vooraf bepaalde, verwachte drukte. Een stresstest voert de belasting bewust verder op om te ontdekken waar de site instabiel wordt of niet meer reageert. Een piektest simuleert een plotselinge toename, bijvoorbeeld na een nieuwsbrief of televisie-uitzending. Bij een duurtest blijft de belasting langere tijd hoog, zodat geheugenlekken, vollopende wachtrijen of andere problemen die langzaam ontstaan zichtbaar worden.

De uitkomst is dus niet één magisch maximumaantal bezoekers. Capaciteit hangt af van wat die bezoekers doen, hoe lang ze blijven en welke systemen hun verzoeken verwerken. Een webshop met veel productpagina’s kan een andere belasting aan dan dezelfde webshop tijdens een actie waarbij duizenden klanten tegelijk een bestelling proberen af te ronden. De test moet daarom passen bij de vraag die je wilt beantwoorden.

Realistische bezoekersscenario’s opstellen

Een bruikbare loadtest begint met een bezoekersscenario, niet met een willekeurig hoog getal. Kijk naar analytics, serverlogs en bedrijfsgegevens om vast te stellen welke pagina’s vaak worden bezocht, wanneer pieken optreden en welke acties belangrijk zijn. Denk aan product bekijken, filters toepassen, zoeken, inloggen en bestellen. Neem ook bezoekers mee die meerdere pagina’s achter elkaar bekijken. Een test die alleen dezelfde URL herhaaldelijk opvraagt, zegt weinig over de belasting van een volledige klantreis.

Bepaal vervolgens hoe de belasting oploopt. Een geleidelijke opbouw kan bijvoorbeeld laten zien bij welk aantal gelijktijdige sessies responstijden beginnen te verslechteren. Een plotselinge piek is geschikter wanneer verkeer in korte tijd binnenkomt. Houd rekening met denktijd: echte bezoekers klikken niet iedere seconde door. Zonder die pauzes stuurt een testtool vaak onnatuurlijk veel verzoeken per gebruiker en ontstaat een belasting die niet overeenkomt met de praktijk.

Maak expliciet onderscheid tussen anonieme en ingelogde bezoekers. Ingelogde sessies kunnen extra databasewerk, personalisatie of toegangscontroles veroorzaken. Ook zoekopdrachten en winkelmandjes zijn vaak zwaarder dan statische informatiepagina’s. Gebruik aannames die je kunt onderbouwen en leg ze vast. Als de verhouding tussen productbezoek en afrekenen later verandert, kun je verklaren waarom testresultaten afwijken. Een scenario is een model van verwacht gedrag, geen exacte voorspelling van iedere bezoeker.

De juiste prestatiemetrics kiezen

Het gemiddelde van alle responstijden vertelt maar een deel van het verhaal. Een kleine groep zeer trage verzoeken kan voor bezoekers een groot probleem vormen, terwijl het gemiddelde er nog acceptabel uitziet. Daarom worden vaak percentielen gebruikt. De 95e percentielwaarde geeft aan binnen welke tijd 95 procent van de gemeten verzoeken klaar is; de overige 5 procent duurde langer. De 99e percentielwaarde maakt uitschieters nog zichtbaarder, maar kan bij kleine aantallen metingen sterk schommelen.

Meet naast responstijd ook het aantal verzoeken per seconde, foutpercentages en de hoeveelheid gelijktijdige sessies. Een fout kan een HTTP-statuscode zijn, maar ook een technisch geslaagde reactie met inhoud die niet klopt, zoals een winkelmandje dat leeg terugkomt. Leg daarom vast welke fouten de testtool herkent en controleer belangrijke gebruikersstromen inhoudelijk. Een snelle foutmelding is geen goede prestatie.

Op infrastructuurniveau zijn CPU, geheugen, schijf- en netwerkgebruik relevant. Voor databases zijn onder meer actieve verbindingen, wachttijden en langlopende query’s nuttig. Bekijk deze gegevens op dezelfde tijdlijn als de bezoekersbelasting en responstijden. Zo is te zien of een verslechtering samenvalt met bijvoorbeeld oplopend geheugengebruik of een volle connection pool. Spreek vooraf grenswaarden af, zoals een maximale responstijd voor afrekenen. Zonder zulke criteria wordt achteraf gemakkelijk geredeneerd dat een resultaat wel meevalt, ook wanneer bezoekers een belangrijke actie niet kunnen afronden.

Een testomgeving kiezen die betrouwbare resultaten geeft

Testen op productie lijkt aantrekkelijk, omdat daar de echte configuratie en data aanwezig zijn. Het risico is dat een zware test echte bezoekers hindert, transacties aanmaakt of systemen van derden overbelast. Een aparte acceptatie- of testomgeving is meestal veiliger, maar levert alleen bruikbare resultaten op als de inrichting voldoende overeenkomt met productie. Verschillen in servercapaciteit, caching, databaseconfiguratie of netwerkroute kunnen de uitkomst vertekenen.

Controleer daarom welke onderdelen gelijk zijn en welke afwijken. Een kleinere testserver kan eerder verzadigen dan de productieomgeving; een gedeelde testdatabase kan juist concurrerende processen bevatten. Noteer zulke beperkingen bij de resultaten. Zorg ook voor representatieve testdata. Een database met tien producten en nauwelijks bestellingen gedraagt zich anders dan een catalogus met honderdduizenden varianten en jaren aan orderhistorie. Data hoeft niet altijd één op één uit productie te komen, maar omvang en verdeling moeten wel geloofwaardig zijn.

Cachegedrag verdient extra aandacht. Een test die steeds dezelfde pagina opvraagt, kan grotendeels uit de cache worden bediend en daardoor veel beter lijken dan een scenario met nieuwe zoekopdrachten of gepersonaliseerde inhoud. Andersom kan een cache die bij iedere teststart leeg is een onrealistische koude start opleveren. Bepaal of je een warme cache, een koude cache of beide wilt meten. Leg de toestand vast, zodat herhalingen vergelijkbaar zijn en verschillen niet ten onrechte aan codewijzigingen worden toegeschreven.

Belasting gecontroleerd opbouwen en variëren

De manier waarop een test belasting opbouwt, bepaalt welke problemen zichtbaar worden. Bij een oplopende test neemt het aantal virtuele gebruikers in stappen toe. Geef iedere stap genoeg tijd om stabiel te worden; anders meet je vooral de overgang en niet het gedrag bij die belasting. Met korte stappen kun je snel een eerste grens vinden, maar kleine schommelingen kunnen dan voorbarig als capaciteitsprobleem worden gezien. Langere stappen kosten meer tijd, maar leveren doorgaans beter vergelijkbare gegevens op.

Een constante belasting is nuttig om een bekende situatie te controleren, bijvoorbeeld het verwachte verkeer tijdens een campagne. Een piekscenario onderzoekt hoe snel de site herstelt nadat verkeer abrupt stijgt en weer afneemt. Een duurtest houdt de belasting uren aan om problemen te vinden die pas na verloop van tijd ontstaan. Denk aan processen die geheugen niet vrijgeven, logbestanden die groeien of achtergrondtaken die achterlopen. Geen van deze testvormen vervangt de andere: een systeem dat een korte piek aankan, kan alsnog instabiel worden tijdens een lange drukke dag.

Controleer ook of de testgenerator zelf voldoende capaciteit heeft. Als de machine die verzoeken verstuurt tegen haar limiet zit, lijkt de website minder belast te worden dan bedoeld. Gebruik waar nodig meerdere generators en meet hun CPU- en netwerkgebruik. Houd tijdens tests wijzigingen aan code, configuratie en infrastructuur bij. Voer niet meerdere ingrijpende experimenten tegelijk uit, want dan is achteraf moeilijk vast te stellen welke verandering de prestatie beïnvloedde.

Knelpunten vinden in applicatie, database en koppelingen

Wanneer responstijden oplopen, is de website niet automatisch de enige oorzaak. Een verzoek kan door browser, CDN, webserver, applicatiecode, database en externe diensten lopen. Verzamel daarom gegevens op meerdere lagen. Hoge CPU-belasting kan wijzen op dure berekeningen of veel gelijktijdige processen. Geheugendruk kan leiden tot opruimwerk of herstarts. Een laag CPU-gebruik sluit een probleem niet uit: applicaties kunnen wachten op databaseverbindingen, netwerkreacties of een gedeelde lock.

Databases zijn vaak een belangrijke bron van vertraging. Queries die bij weinig data snel lijken, kunnen bij grotere tabellen veel rijen doorzoeken. Gebrekkige indexen, lock-wachttijden en een uitgeputte connection pool kunnen vervolgens steeds meer verzoeken ophouden. Kijk niet alleen naar de langzaamste query, maar ook naar hoe vaak die wordt uitgevoerd. Een query van een halve seconde die duizenden keren per minuut draait kan belangrijker zijn dan een zeldzame query die langer duurt.

Externe koppelingen voegen onzekerheid toe. Een betaalprovider, ERP-systeem, zoekdienst of voorraadkoppeling kan trager reageren of verzoeken begrenzen. Meet daarom waar mogelijk afzonderlijk de tijd die de applicatie zelf nodig heeft en de tijd die op een afhankelijk systeem wordt gewacht. Bij een testomgeving moet je afspraken maken over het gedrag van zulke diensten: simuleren is veilig en herhaalbaar, maar mist echte netwerkvertragingen. Echte integraties geven realistischer inzicht, maar kunnen gegevens wijzigen of de dienst onbedoeld belasten. De keuze hangt af van de testvraag en de risico’s.

Testresultaten interpreteren zonder verkeerde conclusies

Lees grafieken in samenhang. Een stijgende responstijd bij gelijkblijvend verkeer kan duiden op een probleem dat zich opbouwt. Een korte vertraging tijdens het opvoeren van de belasting kan daarentegen een overgangseffect zijn. Vergelijk de vorm van de responstijdgrafiek met foutpercentage, throughput en systeemmetingen. Als het aantal verzoeken per seconde niet meer stijgt terwijl het aantal virtuele gebruikers toeneemt, heeft een onderdeel mogelijk zijn verwerkingsgrens bereikt. Als throughput daalt en fouten toenemen, is dat doorgaans ernstiger dan een kleine vertraging zonder fouten.

Let op de verschillen tussen percentielen en op de spreiding. Een goede gemiddelde responstijd naast een slechte 99e percentielwaarde kan betekenen dat een minderheid van de bezoekers lang wacht. Dat kan samenhangen met specifieke pagina’s, cachemissers of transacties die veel databasewerk doen. Splits metingen daarom uit per route of gebruikersactie. Een totaalgemiddelde over de hele site kan een probleem bij zoeken of afrekenen verbergen achter veel snelle homepageverzoeken.

Vergelijk tests alleen als omstandigheden vergelijkbaar zijn: dezelfde dataset, cachetoestand, softwareversie, testduur en belastingopbouw. Herhaal opvallende resultaten, want netwerkruis en achtergrondtaken veroorzaken soms uitschieters. Rapporteer zowel wat goed ging als de beperkingen van de meting. Als een testomgeving bijvoorbeeld een kleinere database gebruikt, is een exact maximumaantal bezoekers niet verantwoord. Een testresultaat is bewijs voor gedrag onder bepaalde omstandigheden, geen garantie dat de site onder iedere toekomstige piek hetzelfde presteert.

Van gevonden probleem naar een herhaalbare test

Een loadtest is vooral bruikbaar wanneer een gevonden probleem kan worden gekoppeld aan een concrete actie. Noteer bij iedere bevinding de stap waarin deze optrad, de belasting op dat moment, de getroffen gebruikersactie en de ondersteunende metingen. Formuleer bijvoorbeeld dat de responstijd van productfilters sterk stijgt wanneer databaseverbindingen verzadigd raken. Dat is informatiever dan de algemene constatering dat de website traag werd. Kies vervolgens een gerichte aanpassing, zoals een query optimaliseren of een cachebeleid wijzigen, en meet opnieuw met hetzelfde scenario.

Verander bij voorkeur één belangrijke factor tegelijk. Als je tegelijk servers opschaalt, code aanpast en caching inschakelt, is mogelijk duidelijk dat de uitkomst verbetert, maar niet waarom. In sommige situaties is een gecombineerde wijziging onvermijdelijk; leg dan vast welke onderdelen zijn veranderd en test later afzonderlijk waar dat zinvol is. Meet ook de keerzijde. Een cache kan responstijden verlagen, maar verouderde voorraad tonen. Meer servercapaciteit kan een databaseknelpunt juist zichtbaarder maken in plaats van oplossen.

Bewaar scenario’s, configuratie, testdata-afspraken en meetresultaten samen met de versie van de website. Zo wordt een prestatietest herhaalbaar na een release en kan een regressie eerder worden opgemerkt. Automatiseer waar passend een beperkte test die belangrijke routes controleert, maar gebruik die niet als vervanging voor een uitgebreide capaciteitstest. Een korte controle is geschikt om grote achteruitgang te signaleren; het gedrag bij langdurige piekbelasting vraagt een andere testduur, bewaking en analyse. Houd bovendien rekening met geplande wijzigingen in campagnes, catalogusomvang en externe koppelingen, want ook die veranderen het belastingprofiel.