Deepdive sessie: performance testing, met de voeten in de klei

Zoals elke eerste vrijdag van de maand hebben we vrijdag 4 maart weer een deepdive gehad. Deze keer was het onderwerp Performance testen. Een onderwerp wat al een keer de revue had gepasseerd, maar waarvan we allemaal zeiden dat het nuttig was om er dieper op in te gaan. Waar we de vorige keer veel theorie hebben gehoord over wanneer je performancetesten inzet, hebben we nu met onze poten in de modder gewroet. Menno Pot had, net als vorige keer, voor een groot deel de inhoud verzorgd, maar gelukkig gaf hij ons genoeg ruimte om zelf aan de slag te gaan en te ontdekken hoe dat eigenlijk werkte.

Ik was erg nieuwsgierig naar deze deepdive sessie, want performance testen vind ik ontzettend interessant. Menno verzorgde, net als vorige keer, voor een groot deel de inhoud. Gelukkig gaf hij ons genoeg ruimte om zelf aan de slag te gaan en te ontdekken hoe dat performance testen eigenlijk werkt.

Rond een uur of 2 kwamen we bijeen met alle pre-requisites op de laptop. Java geïnstalleerd, node.js gedownload en Jmeter in de aanslag! Menno had ter voorbereiding in een mail alvast een databaseje gestuurd, in een json formaat (zie afbeelding), dat hij db.json noemde, en een klein scriptje geschreven in Jmeter. Dit gebruikten we als startpunt.

Aan de slag met performance testing

Het eerste wat we mochten doen, was een json-server starten met node.js, zodat we een endpoint (localhost) hadden om tegen te schreeuwen. Een “npm install -g json-server” en “json-server –watch db.json” later konden we verder aan de slag.

Met Jmeter konden we het script uitproberen en uitbreiden. Als er een makkelijke manier is om met performancetesten aan de slag te gaan dan is het deze wel, want de deepdive was nog geen half uur begonnen of onze CPU liep al uit zijn voegen. Terwijl we eerst ook nog even een kleine opfriscursus van Menno kregen dat je rekening moet houden met de zwakste “lijntjes” binnen je testomgeving. Als je met 1 pc bijvoorbeeld verschillende gebruikers probeert te simuleren, dan loop je al snel tegen de beperkingen aan van dat systeem. Daardoor ben je dan misschien meer dat systeem aan het performancetesten dan je SUT.

Zoals in de CPU usage bij ctrl+shift+esc op windows PC’s te zien was, draaide de json server overduidelijk maar op 1 thread. Hier zag je dat de CPU de belemmerende factor was. Toen we hierbij een tweede server opstartte met ieder een logische kern (1 van de 12 zoals hier), haalden we een stuk hoger aantal transacties per seconde (TPS).

Het effect van meer users

Leuk om te zien was hoe je door andere instellingen in JMeter het aantal users geleidelijk kon verhogen. Zo kon je bijvoorbeeld instellen dat bij een doorlooptijd van 10 minuten, steeds meer users tegelijk de API moesten bevragen. In onderstaande grafiek is te zien aan de rechte blauwe lijn, dat er steeds meer users bijkomen. Aan de onderste blauwe lijn zie je dat de responsetijd snel langer wordt met als gevolg dat het aantal TPS (rode lijn) al snel amper meer toeneemt. Dat er meer users bijkomen maakt dan geen verschil meer. Elke user moet gewoon langer wachten op een antwoord alvorens hij weer een nieuwe call kan uitsturen.

Ook een kickstart?

Al met al was het weer een zeer interessante deepdive. Mijn belangrijkste conclusie is dat performance testen helemaal niet zo “eng” is als je misschien denkt. Ga er gewoon eens voor zitten. Binnen een half uur heb je alle benodigdheden om van start te gaan. Hoe verder je er induikt hoe beter je er in wordt en hoe slimmer je de data kan interpreteren. JMeter heeft ook nog eens legio plug-ins om te installeren waarmee je nog meer data kan verwerken.

Het verslag van de vorige deepdive sessie: performance testing vind je hier.

Wil jij ook met performance testen aan de slag? Neem dan vooral even contact met me op, dan geef ik je graag een kickstart! Jurgen Alebregtse (jurgen@newspark.nl).