Performance testing is een essentieel onderdeel voor het creëren van een optimale gebruikerservaring voor je website of app. Met een te langzaam platform verlies je immers gebruikers en het levert veel frustratie op. Maar hoe pak je dit aan als je niet duizenden, maar miljoenen bezoekers op je platform verwacht? Wat heb je nodig om zo’n grootschalige test te laten slagen? In deze blog deel ik, op basis van de ervaring die ik heb opgedaan in dergelijke projecten, de 8 voorwaarden voor succes bij grootschalige performance testing.
1: Gebruik de cloud
Om een goede test uit te voeren is het van belang de praktijksituatie zo goed mogelijk na te bootsen. Maar hoe simuleer je 2 miljoen gebruikers die allemaal binnen 7 seconden via een app een stem uitbrengen? Voor het testen van platformen met minder dan 250.000 gebruikers zetten we bij Computest onze eigen load farm in. Als je echter miljoenen gebruikers nodig hebt die tegelijkertijd een actie uitvoeren, zijn er veel meer load-generatoren nodig die gebruikers simuleren. Deze huren we onder meer in bij Amazon. Zij hebben datacenters in alle regio’s waardoor we met behulp van de cloud in staat zijn vanuit de hele wereld gebruikers te simuleren. Daarmee ben je bijvoorbeeld als internationaal opererende retailer ook in China verzekerd van voldoende performance.
2: Weet wat je aankan
Daarnaast is het belangrijk om te weten wat een load-generator maximaal aan gebruikers kan simuleren. Test dus eerder in een kleinere vorm met één of enkele load-generatoren om te zien hoeveel virtuele gebruikers je load-generator veilig aankan. Het is namelijk niet praktisch om teveel generatoren te gebruiken; naast de kosten kan het gebeuren dat je controller de hoeveelheid load-generatoren niet meer kan aansturen.
3: Bepaal waar de testdata vandaan komt
Om miljoenen gebruikers tegelijk te simuleren, is het vaak belangrijk dat elke gebruiker unieke testdata heeft, zoals gebruikersnaam/wachtwoord-gegevens of meer. Deze lijsten met miljoenen regels testdata worden snel te groot om snel te kunnen behappen door de controller. Tevens zullen alle gesimuleerde gebruikers steeds aan de controller een unieke regel moeten opvragen. Dat gaat met zoveel requests per seconde dat de controller alleen al voor die taak overbelast kan raken. Het is een best practice om dan een specifieke inrichting op te zetten die de testdata uitgeeft aan de users. Wij hebben een eenvoudige webserver/database opstelling gemaakt die duizenden unieke accounts per seconde kan serveren. Hiermee verlagen we de belasting op de controller en zorgen we toch voor unieke uitgiftes van testdata. Neem bijvoorbeeld een test op het uitbrengen van een stem binnen een app. Daarvoor moet de gebruiker geverifieerd worden en het login-proces hebben voltooid (wat geen onderdeel was van de test). Het resultaat van de login is een token/sleutel die is aangemaakt bij de ‘registratie-run’. Als je meer dan een miljoen van die tokens in een bestand hebt, dan wordt het databestand te groot om werkbaar te blijven voor de performance testapplicatie.
4: Zorg voor een goede planning (bouw reservetijd in)
Test-iteraties nemen veel tijd in beslag. En bij een grootschalige test heb je doordat je verbinding maakt met veel meer agents, logischerwijs nog meer tijd nodig. Het maakt ook een groot verschil of je met testresultaten van 1000 of een miljoen gebruikers werkt. Houd daar dus rekening mee in je planning. Om een idee te geven; bij een gemiddelde test kun je met gemak 20 test-runs per dag uitvoeren, bij een test met 2 miljoen gebruikers is dat maximaal 6. Ga er ook niet vanuit dat je test direct goed gaat. Er zijn altijd een aantal dry runs nodig voordat je de daadwerkelijke test kunt uitvoeren. De load-generatoren en de cloud-systemen die deel uitmaken van de test moeten daarnaast ook eerst opwarmen.
5: Zorg dat je applicatie schaalbaar is
Om verschillende capaciteiten te testen is het belangrijk tijdens het testen te kunnen opschalen. Daarbij gaat het niet alleen om de load-generatoren, maar ook om de applicatie. Daarmee kan op verschillende capaciteiten worden getest. Als er gebruikgemaakt wordt van een eenvoudig te schalen systeem kunnen er snel systemen worden bijgeschaald als blijkt dat de omgeving tijdens de vooraf uitgevoerde dry runs op lage load de uiteindelijke requirements niet gaat halen. Het is daarom ook van belang dat sysops betrokken zijn bij de uitvoer van de testen.
6: Tune je controller
Een belangrijke factor om rekening mee te houden bij grootschalige performance testing, is de bandbreedte van de controller en load-generatoren. En daarnaast de capaciteit van de controller die het geheel aanstuurt (CPU en memory). Als dit niet op orde is worden de zogenaamde ‘run time graphs’ van de test niet goed en tijdig geüpdatet waardoor je geen controle hebt over de test. Er wordt zoveel data verzonden dat je niet meer ziet wat er gebeurt. Je moet dus volledig kunnen vertrouwen op je graphs. Naast het feit dat je mogelijk weinig controle meer hebt, is het ook van cruciaal belang voor de test, dat je eigen testopstelling niet de bottleneck is van de test. Als je controller of load-generatoren het niet meer aankunnen dan faalt de test.
7: Werk met robuuste scripts
Functionele problemen van je platform kunnen ervoor zorgen dat je geen reëel beeld krijgt van je performance test. Daarom moet je, zeker voordat je start met grootschalige performance testing, zorgen dat de functionele flow goed werkt en is getest. Zo weet je als er bij je performance test errors naar boven komen, dat deze ook daadwerkelijk performance gerelateerd zijn. Bovendien is het met een enorm aantal gebruikers heel moeilijk om functionele problemen te signaleren. Dit heb ik ervaren bij een test voor een online retailer. In de flow voor het bestellen van schoenen ontbrak maat 42 als keuzemogelijkheid, een functionele error. Als dit voorkomt wanneer je met een hoge load test, dan kan dit enorm veel fouten geven. Die hoeveelheid fouten zorgen er weer voor dat je testopstelling het niet meer kan verwerken. Een foutpercentage van maar 0,1% zijn al duizenden fouten (per seconde). Probeer dan nog maar eens de echte fouten eruit te halen die performance gerelateerd zijn. Dit levert veel vertraging op wat zonde is van de tijd en capaciteit die je erin steekt. Start ook een test op ‘relatief’ lage load (100.000 gelijktijdige gebruikers) om de scripts en testomgeving te valideren. Daarmee kunnen de eerste issues al zichtbaar worden.
8: Haal de juiste performance testing tools in huis
Het spreekt voor zich dat je voor dergelijke testen niet alleen een goede infrastructuur moet hebben, maar ook de juiste tools moet inzetten. Computest werkt hiervoor nauw samen met Neotys. De tool Neoload wordt bij internationale en Nederlandse organisaties toegepast voor grootschalige performance testing en specifiek ontwikkeld om snelle en krachtige testen uit te voeren.
Meer weten over hoe je een grootschalige performance test opzet en uitvoert? Lees deze case story of mail via info@computest.nl.
Raymond Steenvoorden
