Het REVA-project doorgemeten

Momenteel ben ik bij de ICTU in Den Haag gedetacheerd, waar ik hoofdzakelijk aan het REVA-project werk. REVA staat voor Registratie Eerste Verblijfadres Arbeidsmigraten en heeft als belangrijkste functie het registreren (en controleren) van het verblijfadres van arbeidsmigranten. Dit is een webapplicatie, gebaseerd op Wicket, draaiend binnen Apache Karaf met een Virtuoso-database. Via de webapplicatie kan men onder andere registraties zoeken, nieuwe mensen registreren en rapporten opvragen. De eindgebruikers zijn diverse gemeentes in Nederland.

Verwachte groei / business case

Het aantal gemeenten dat nu gebruik maakt van de applicatie is 6. In de toekomst verwacht men dat dit groeit naar 18 en wellicht wordt het project landelijk uitgerold. In het kader hiervan is het belangrijk om te weten of de applicatie en infrastructuur aan deze vraag zal blijven voldoen. Daarom dient de huidige en (verwachte) toekomstige performance te worden gemeten. Dit gebeurt via de open source-applicatie Jmeter.

Jmeter

Jmeter is net als de REVA-applicatie, volledig gebouwd in Java. Via Jmeter kunnen diverse onderdelen van een applicatie worden gemeten: aantal transacties per tijdseenheid, meten van verschillende onderdelen van een applicatie zoals de gebruiker deze ook doet (inloggen, opzoeken, invoeren, opslaan, etcetera), doorvoersnelheid per tijdseenheid, etcetera. Ook kunnen bijvoorbeeld netwerkgebruik, processorbelasting en geheugengebruik gemeten worden. Het aantal parallele gebruikers (threads) kan zelf worden ingesteld tussen 1 en N. Alle resultaten kunnen worden gelogd en er kunnen rapporten en grafieken van gemaakt worden. Via een aantal goede plugins is er nog meer mogelijk. Al met al biedt Jmeterzeer uitgebreide mogelijkheden om diverse performancegerelateerde vraagstukken te meten en te rapporteren.

Uitgangspunten

Voordat de eerste meting wordt opgezet/ingeregeld moet er duidelijk worden bepaald wat er onder welke omstandigheden wordt gemeten en met welk doel. Eén en ander moet worden vastgesteld middels het opstellen van een aantal (basis) uitgangspunten. Een aantal van deze uitgangspunten zijn:

• Er is een testomgeving beschikbaar die op het moment van uitvoeren van de testen dedicated beschikbaar is voor de performancetest. Deze omgeving is gelijkwaardig aan de minimaal verwachte productiesituatie.

• De inhoud van de testdatabase is zowel op aantallen als verhoudingen vergelijkbaar met de verwachte productiesituatie.

• Alleen de meestgebruikte functionaliteit wordt gemeten, uitgebreid met wat performancegevoelige acties, zoals genereren document, ophalen data enzovoort.

Inladen representatieve gegevens

Het is belangrijk om verschillende testen te doen op basis van representatieve gegevens. Bij het REVA-project is er een aantal processtappen die uitgevoerd zijn, voordat het daadwerkelijke meten begon. In het kort zijn dat deze:

• Inladen gebruikers in LDAP met bijbehorende rollen → hiervoor is ook Jmeter gebruikt

• Inladen grote aantallen registraties om de database te vullen naar productiemaatstaven → moet bij elke test weer opnieuw

• Verwijderen registraties / LDAP-gebruikers na afloop van de test

• Tijdens de testen werd o.a. gemeten wat de resultaten waren in geval van:

• Een volledig lege database

• Het insturen van x-aantal gebruikers (bv. 1.000) op basis van 1 gebruiker die tegelijkertijd actief is

• Het insturen van x-aantal gebruikers (bv. 1.000) op basis van 5, 10, 15, 25, 50 gebruikers die tegelijkertijd actief zijn

• Bovenstaande testen maar dan met een database waarin reeds 1.000, 100.000, 200.000 en 500.000 registraties in waren opgeslagen

Dit valt allemaal onder inladen representatieve gegevens om de daadwerkelijke huidige en toekomstige productie situatie zo goed mogelijk te representeren.

Benodigdheden

De software die voor de metingen is gebruikt:

• Jmeter zelf (https://jmeter.apache.org/)

• Website om data files (in CSV format) te genereren: https://www.mockaroo.com

• De volgende Jmeter plugins: jmeter plugins standard en extra (http://jmeter-plugins.org/downloads/all/)

• De server agent (op de server waar de applicatie draait) (http://jmeter-plugins.org/downloads/file/ServerAgent-2.2.1.zip)

• Diverse scripts om de log files te verwerken:

  • Om PNG-grafieken te maken o.b.v. log files

  • Om log files beter leesbaar te maken

  • Om log files per tijdseenheid te aggregeren (bijvoorbeeld per minuut)

• Office-pakket voor verzamelen van testresultaten

De testen zelf

Voordat de testen zijn uitgevoerd, werd er eerst een hoeveelheid data ingeladen: gebruikers in LDAP, koppelingen van rollen aan gebruikers, testregistraties in DB geladen, etcetera. Deze testen worden hier buiten beschouwing gelaten, omdat deze zaken niet in productie worden gedaan. De focus is op de testen zelf, zoals deze ook in de praktijk voorkomen. De belangrijkste scenario’s worden getest, waarbij deze test hier verder wordt uitgelegd: “het invoeren van een registratie”. Per stap is een screenshot genomen van de opzet en parameters.

Registratie aanmaken

De hoofdgroep, waarin alle testonderdelen zitten die van belang zijn. Hierin kan men onder meer aangeven:

• Hoeveel gebruikers/threads tegelijkertijd actief moeten zijn (1-N). Er is begonnen met 1 actieve thread, daarna is dit aantal opgeschroefd naar 5, 10, 15, 25 en 50.

• Ramp up period: de periode die moet worden gewacht voordat er een nieuwe request naar de server wordt gestuurd. Deze is op 1 gezet, sneller dan dit zal in praktijk niet nodig zijn.

• Loop count: hoevaak wordt er een registratie ingeschoten. Bij 1x wordt er 1 registratie ingeschoten, bij foreverworden er zoveel registraties ingeschoten als de data file bevat. De data file betreft een CSV-file met labels en waarden die bij de registratie horen. In onze testgevallen waren dat er vaak 1.000. Deze datafile is gegenereerd, mede op basis van de volgende website: https://www.mockaroo.com

Figuur 1: registratie aanmaken: parameters om de test in te stellen.

Opslaan van data: post action

Nadat de basisgegevens zijn ingevuld, worden de daadwerkelijke acties uitgevoerd, die leiden tot een registratie: van inloggen, via gegevens invullen, tot opslaan. Via name-value-parameters worden de waarden uit de CSV-file waar de registraties instaan ingevuld in de velden van de applicatie. Bijvoorbeeld openbareRuimteFeedback met waarde ${straatnaam}.

Figuur 2: opslaan van variabele waarden via Jmeter-interface

Grafieken

Als alle testen succesvol zijn doorlopen worden er (binnen Jmeter) grafieken gegenereerd die visuele inzage geven in de performancemetingen. Als voorbeeld in figuur 3 is onder andere te zien hoeveel registraties per minuut er gemiddeld kunnen worden verwerkt. Dit zijn er in dit geval 113 per minuut. De grafieken kunnen ook op een later tijdstip alsnog worden gemaakt. Zie hiervoor kopje “logging”.

Figuur 3: grafieken met grafische weergave van performance tests.

Results table

De results table laat alle individuele acties zien met enkele van hun karakteristieken:

• sample nummer (testnummer)

• starttijd

• sample time (tijdsduur van de actie)

• status van de actie: groen icoon is succesvol, oranje betekent een warning, waarbij de logging kan worden bekeken

Figuur 4: results table met details per uitgevoerde actie.

Resource monitoring

Voor elke test is het ook mogelijk om de resources van de server te monitoren en grafisch in kaart te brengen. Wat er onder andere gemeten kan worden zijn:

• hoeveelheid gebruikt en vrij geheugen,

• hardeschijfruimte

• swap geheugengebruik, netwerksnelheid

• en heel belangrijk: CPU-gebruik.

Figuur 5: resource monitoring tijdens een test.

Response times over times

Het is heel belangrijk om te weten wat de responsetijden van de individuele acties per tijdseenheid zijn. Hiervoor kan ook een grafiek worden gegenereerd. Per actie (inloggen, opzoeken, opslaan, etcetera) is te zien hoeveel milliseconde (ms) de actie duurt. Men kan het aantal threads (aantal parallel werkende gebruikers) variëren en zo de responsetijden met elkaar vergelijken.

Figuur 6: responsetijden per tijdseenheid gedurende een test.

De laatste grafiek laat zien wat de responsetijden zijn in relatie tot het aantal threads dat tegelijkertijd ingesteld is. Men ziet bijvoorbeeld dat het opslaan gemiddeld 2.9 seconden duurt als er 1 thread actief is en dat de BAG-check binnen 0,6 seconden wordt uitgevoerd. Indien de response time niet significant toeneemt met het verhogen van het aantal threads, is de performance dus niet in het geding.

Figuur 7: response time versus threads.

Log files analyseren

Jmeter biedt hele goede mogelijkheden om de testresultaten te loggen. Bijna elke stap in het meetproces kan in een aparte log file worden opgeslagen. Standaard wordt een logfile in het JTL-formaat (net als een CSV-bestand) opgeslagen, dat daarna verder verwerkt kan worden. In het geval van de logs van de REVA performance tests is ervoor gekozen om de logs als volgt te verwerken:

• Van alle log files is een grafiek gegenereerd via een custom script. Dat script ziet er als volgt uit: ./JMeterPluginsCMD.sh –generate-png grafiek.png –input-jtl logfile.csv –plugin-type PerfMon –width 800 –height 600

• Veel log files bestaan uit een zeer groot aantal meetpunten. Het is handig om al deze meetpunten per minuut te aggregeren. Zo krijgt men bijvoorbeeld een nette grafiek met maximaal 1.000 meetpunten, verdeeld over een tijdsduur van 1 uur (60 punten op de horizontale as). Dit als voorbeeld, dat er bijvoorbeeld 1.000 registraties zijn opgeslagen en de totale testduur dan 60 minuten duurde. Dan blijven zaken behapbaar.

En nu?

Zelf de manual lezen en verder experimenteren met Jmeter op https://jmeter.apache.org/usermanual/get-started.html