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:
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