Wanneer je nieuwe features toevoegt aan een applicatie of bestaande features uitbreidt ga je er altijd vanuit dat je het goed hebt gedaan. De functionaliteit werkt zoals beschreven en de performance is optimaal. Toch? Of de functionaliteit werkt zoals beschreven is relatief makkelijk te valideren: bekijk de beschrijving en loop het scenario door zoals de gebruiker dat ook zou doen. Maar hoe doe je dat eigenlijk voor performance?
Voorbereiding
Je kan beginnen door te bepalen hoeveel gebruikers er gebruik gaan maken van je nieuwe of aangepaste feature. Dit doe je door te kijken naar je metrics, bijvoorbeeld door te kijken naar het aantal bezoeken in je server logs. Wij gebruiken StatsD en Kibana (lees hier meer over in onze andere blogs) om de server logs te analyseren. Eventueel kan je ook kijken naar de statistieken van je Online Marketing tool zoals Google Analytics of Hotjar.
Als je weet hoeveel gebruikers je applicatie gebruiken, bepaal je het gewenste aantal requests per minuut.
Stel: Het endpoint dat je wilt testen krijgt gemiddeld genomen 7800 requests per uur. Dan is het aantal requests per minuut: 7800/60 = 130.
Uitvoering
Wij maken gebruik van de dienst Load Impact. Daarmee kan je het scenario dat je wilt testen uitschrijven in een JavaScript bestand. Één bestand kan meerdere scenario’s bevatten. In dat bestand kan je ook instellen hoeveel gebruikers je wilt simuleren en wat de looptijd van je test moet zijn. Elke virtual user (gebruiker) loopt de uitgeschreven scenario’s gedurende de looptijd elke keer opnieuw door. Load Impact voert geleidelijk het aantal gebruikers op om een zo realistisch mogelijk gebruik te simuleren.
Aan het eind van de test kan je het maximale aantal requests per minuut zien dat behaald is tijdens je test. Je kan het aantal requests verhogen of verlagen door het aantal virtual users te verhogen of door het aantal calls dat elke virtual user doet aan te passen. Wanneer je test dus ongeveer het aantal requests per minuut doet dat je verwacht, dan heb je ook een benadering van de performance van je endpoint bij het verwachte gebruik.
Om een nog realistischer gebruik te simuleren kan je verschillende scenario’s (endpoints) combineren in één load test. Dan weet je wat de performance van je applicatie is bij een realistisch gebruik van verschillende functies.
Stress testing
Je kan deze methodiek ook toepassen om te stress testen. Het verschil tussen stress testing en load testing is dat je bij stress testing gaat proberen om het systeem te overladen met verzoeken, zodat je weet bij hoeveel gebruikers de applicatie niet meer bruikbaar is. Dit kan je doen door verschillende scenario’s te combineren en de test een aantal keer uit te voeren met een oplopend aantal gebruikers. Dit herhaal je totdat de server de verzoeken niet meer kan verwerken.
Waarom doen we dit eigenlijk?
Onze high availability applicaties ondergaan voorafgaand aan elke release een load test. Zo weten we precies of de wijzigingen aan de applicatie geschikt zijn om in productie te nemen. We valideren daarmee ook of snelheidsverbeteringen ook echt de beoogde verbetering voor de gebruiker geven. Daarnaast kunnen we de resultaten ook analyseren om de ‘bottlenecks’ (de langzaamste onderdelen) van de applicatie te identificeren. Die onderdelen kunnen we dan in een volgende sprint weer wat aandacht geven. Stress tests helpen ook om die bottlenecks te identificeren en zorgen er bovendien voor dat je precies weet bij hoeveel gebruikers de hardware van je server platform niet meer voldoet. Zo kunnen we op tijd met onze hostingpartij schakelen om te zorgen dat de systemen opgeschaald worden.
Meer weten, of een keer komen kijken hoe we dit regelen? Je bent altijd welkom voor een kop koffie!
