Het doel van een load test is om op een zo realistisch mogelijke wijze netwerkverkeer en gedrag van bezoekers te simuleren om de performance van de applicatie goed te meten. Hiervoor worden virtuele bezoekers ingezet. Voor een goede performancetest is het echter cruciaal te bepalen waar die load van virtuele bezoekers vandaan moet komen. Lees in dit blog meer over de vier opties en welke afwegingen je moet maken om de juiste te kiezen.
Optie 1: Load vanuit dezelfde infrastructuur
Het is belangrijk om te testen vanaf de plek waar je echte gebruikers zitten of waar je load vandaan komt (API-calls kunnen dus wel vanuit het interne netwerk komen). In bijna alle gevallen komen je gebruikers vanaf het internet, buiten je eigen infrastructuur, dus moet je deze gebruikers ook vanaf het internet simuleren. Je kiest hier dan voor één of meerdere externe locaties om je gebruikers/ load vanaf te simuleren. Op deze wijze raak je ook de hele voorkant van de infrastructuur die je als je vanuit het interne netwerk test, meestal mist. Je netwerkconnectiviteit, routers, firewalls en load balancers raak je nu wel. Belangrijk is dan meestal ook dat je test vanuit zoveel mogelijk IP-adressen, omdat dit vaak invloed heeft op je load balancing en firewall. Zeker bij netwerk intensieve testen komt het regelmatig voor dat er op dit vlak nog veel niet optimaal is geconfigureerd of zelfs fouten geeft. Deze fouten of niet optimale configuratie mis je wanneer je niet vanuit een externe locatie test.
Optie 2: Load vanuit een externe locatie
Een andere belangrijke factor bij het testen vanuit een externe locatie is dat responstijden beter worden gemeten. Intern meten geeft meestal een te rooskleurig beeld en daarnaast worden requests sneller dan normaal afgehandeld. Ook dit kan weer impact hebben op de totaal mogelijke capaciteit. Connecties worden bijvoorbeeld minder lang open gehouden en connectieproblemen zullen dus minder snel optreden dan in de praktijk. Een performanceprobleem dat we in heel veel gevallen zien optreden. Met externe testen tackel je dit over het algemeen wel goed.
Optie 3: Load vanuit gedistribueerde public cloud locaties
Vanuit een externe locatie testen is belangrijk en realistisch, maar nog realistischer wordt het als je ook je (geografische) locaties uitbreidt. Zeker ook met het toenemende gebruik van CDN’s voor het distribueren van veel statische content wordt het belangrijker om te testen vanuit fysiek verschillende locaties zodat de CDN’s ook beter worden geraakt. Wil je dit kunnen doen, dan is het gebruik van cloud-diensten zoals AWS, Azure, RackSpace et cetera onvermijdbaar. De grotere cloud-diensten bieden wereldwijd verschillende locaties. Elk continent heeft vaak twee of meerdere locaties waar systemen gehuurd kunnen worden om gebruikers/ load vanaf te simuleren. Dit geeft als meerwaarde dat je responstijden vanaf deze locaties kunt meten. Een gebruiker vanuit de VS kent altijd hogere responstijden wanneer deze een datacenter in Europa raakt, vanwege de hogere latency. Kent je applicatie een grote geografische spreiding, dan ontkom je niet aan het gebruiken van dit soort cloud-diensten.
Optie 4: Specifieke gebruikerslocatie
Een ander voordeel van deze clouddiensten is dat je tijdelijk heel veel systemen kunt huren om grootschalige performancetesten te kunnen uitvoeren. Je kunt deze volledig afgestemd op jouw wensen afnemen. Een paar systemen met veel geheugen en CPU-kracht, of heel veel kleine systemen veel een betere spreiding. Tegenwoordig bieden praktisch alle bekende commerciële performancetesttools een integratie met dit soort cloud-diensten. Vanuit de tool kunnen deze systemen direct tegen betaling worden gehuurd. Je hoeft dan zelf niet deze systemen te configureren en beheren. Eenvoudig, maar daar staan natuurlijk wel kosten tegenover.
Soms komen gebruikers vanaf specifieke locaties die een andere benadering nodig hebben dan simpelweg testen vanaf het internet. Kantoormedewerkers komen logischerwijs vanaf de kantoorlocaties. Je zou dan de gebruikers die de kantoorapplicatie(s) gebruiken ook simuleren vanaf een medewerkerslocatie. Het is dan gebruikelijk dat echte desktops worden voorzien van de loadgenerator-software en het gebruik vanaf deze desktop(s) wordt gesimuleerd. Meestal worden dan enkele desktops aangewezen waar het gebruik vanaf kan worden gesimuleerd. Het is belangrijk om dat op deze manier te doen, in plaats vanaf het datacenter, omdat je zo de exacte route volgt die de gebruiker ook volgt. Lokale netwerkconfiguratie, beperkte bandbreedte vanaf een desktop en mogelijk andere beperkingen neem je dan mee.
Leerlingen vanuit scholen kennen ook zo hun eigen karakter. Zo zijn er veel leerlingen die tegelijk vanaf dezelfde school (en klas) een educatieapplicatie gebruiken. Vaak zelfs allemaal over een wifi-aansluiting. Test je vanuit je eigen datacenter, dan zul je geen netwerkproblemen vinden. Simuleer je leerlingen vanaf 30 wifi-devices, op de echte schoollocatie, dan zie je zeker andere resultaten. Wellicht is dit het probleem binnen de school, het is wel wat de gebruiker ervaart en waar je als applicatie-owner op wordt aangekeken.
Dit laatste is lastig te simuleren, maar wat ik wil aangeven is dat het te allen tijde belangrijk is om zoveel mogelijk na te gaan waar je gebruikers zitten en zoveel mogelijk deze locatie(s) te simuleren of te benaderen. Zo krijg je de meest realistische resultaten, vind je de werkelijke bottlenecks en werk je uiteindelijk toe naar de beste gebruikerservaring.
Computest Loadfarm
Bovenstaande opties zouden je voldoende houvast moeten geven bij het maken van een keuze. Computest biedt ook de mogelijkheid voor het huren van loadgeneratoren in onze Loadfarm. Deze zijn helemaal op maat gemaakt, getuned voor het simuleren van hoge hoeveelheden gebruikers en beschikt desgewenst over 2.000 IP-adressen voor een realistische simulatie.
Mocht je nog vragen hebben of meer informatie willen, mail dan naar performance@computest.nl.