Als je binnen JMeter iets wilt doen wat niet standaard in de tool zit, gebruik je plugins of ga je zelf code schrijven. In het geval dat je zelf code gaat schrijven, wordt aangeraden de groovy functie en JSR223 sampler te gebruiken.
Ik wil hieronder graag bespreken welke mogelijkheden deze 2 opties je bieden, maar ook waar ik de beperkingen hiervan zie.
Groovy JMeter functie
In JMeter heb je de __groovy functie. Je kan hier je eigen code in kwijt, maar je kan ook een functie aanroepen uit een (eigen geschreven) groovy file.
Voor de laatste optie moet je property groovy.utilities definiëren met het pad naar de groovy file.
Deze property is beschikbaar in jmeter.properties. Na aanpassen van de property is een herstart van JMeter vereist.
JMeter bevat in de installatie ook een voorbeeld (zie jmeter.properties van je eigen JMeter installatie). Daarin wordt verwezen naar bin/utility.groovy en daarin staat een factorial functie. Aanroepen van deze functie kan dan via:
${__groovy(factorial(10))}
Het grootste nadeel van de JMeter functies, waar __groovy er 1 van is, is dat ze niet overal gebruikt mogen/kunnen worden:
Waarvan, voor mij, de belangrijkste het “Script” veld is van de JSR223 sampler.
Het gebruik van de groovy functie kan in mijn ogen vooral heel handig zijn bij het definiëren van waardes van variabelen (User Defined Variables of User Parameters). Maar ik denk niet dat het handig is voor uitvoerende functies zoals het openen van bijvoorbeeld een database connectie of een MQ queue connectie omdat er geen goede plek is om deze functies uit te laten voeren (het werkt in ieder geval niet vanuit het Script veld van de JSR223 sampler).
JSR223 sampler
De JSR223 sampler is de andere aangeraden manier om zelf code te schrijven.
Bij het gebruik van de JSR223 sampler kan je op 2 manieren groovy code aanroepen/uitvoeren. Dit zijn:
Gebruik van veld “Script file (overrides script) -> File Name”
Code schrijven in “Script” veld
JSR223 sampler – Script file
De eerste optie spreekt voor zich: Je kan verwijzen naar een groovy file die de code bevat die je uit wil voeren. Hierbij kan je ook parameters meegeven. Deze kan je bijvoorbeeld gebruiken om de code wat generieker te maken. Je kan dan bijv. code maken voor het connecten met een MQ queue waarbij de parameter de queue naam bevat.
Je kan vanuit de JSR223 sampler geen functies aanroepen binnen die groovy file. Je zou hier wel een work-around voor kunnen bedenken zoals een switch statement die een parameter met functie naam als input gebruikt en op basis daarvan een functie aanroept. Voorbeeld:
String function = args[0]
switch (function) {
case "factorial":
factorial(10)
break
case "someFunction":
someFunction()
break
}
def factorial(n) { n == 1 ? 1 : n * factorial(n - 1) }Het grote nadeel van “externe” groovy scripts vind ik dat je het JMeter script moet “verlaten” om de code te bekijken of te bewerken.
Dit probleem is opgelost door de code in het Script veld te zetten. Het nadeel hiervan is dan weer dat je (mogelijk) die code op meerdere plekken in je JMeter script gaat krijgen. In het volgende stuk bespreek ik welke manieren ik gevonden heb om daarmee om te gaan.
JSR223 sampler – Script veld
Mijn voorkeur heeft dus het schrijven van de code in het veld Script van de JSR223 sampler. Wat zijn dan de manieren om te voorkomen dat de code niet op meerdere plekken in het JMeter script terecht komt? Dit heeft vooral te maken met de plaatsing van de sampler en de vulling ervan. Ik heb dit opgesplitst in 2 manieren:
Gebruik van Test Fragments
Functies definiëren en in props of vars zetten
JSR223 sampler – Script veld – Test Fragments
Je kan een Test Fragment maken en met behulp van een Controller verschillende JSR223 samplers daar onderbrengen. Vanuit de Thread Groups kan je dan door middel van de Module Controller deze functies aanroepen. Voorbeeld:
Deze methode werkt heel fijn. Deze functies kan je echter niet aanroepen met parameters. Ik gaf eerder het voorbeeld bij de JSR223 sampler dat je bijvoorbeeld code kan schrijven voor het openen van een MQ queue connectie en dat je dan de parameters kon gebruiken om bijv. de queue naam mee te geven. Dat werkt nu niet. Ik heb dit opgelost door voor het aanroepen van de functie de waardes van een aantal JMeter vars aan te passen m.b.v. User Defined Variables, User Parameters of JSR223 sampler.
Een nadeel van deze methode, los van gemis van gebruik van parameters, is dat je alsnog per functie een aanroep controller (module controller) nodig hebt. Mijn voorkeur is 1 JSR223 sampler waarin je de verschillende functies aanroept die je nodig hebt in een iteratie. Dit komt de leesbaarheid van het script ten goede. Hoe je dit doet, wordt in het volgende stuk beschreven.
JSR223 sampler – Script veld – Functies in props of vars
Een andere mogelijkheid om de groovy code modulair te maken, is door de referentie naar een functie op te slaan in een prop of var:
props.put('factorial', this.&factorial)
vars.putObject('factorial', this.&factorial)En verder in het script weer aan te roepen:
def factorial = props.get('factorial')
factorial(10)of in 1 regel:
props.get('factorial')(10)Voor vars gebruik je dan vars.getObject(‘factorial’).
Het gebruik van groovy code op deze manier heeft zijn voor- en nadelen.
Je hebt meerdere mogelijkheden om dit te doen. Een aantal die ik geprobeerd heb:
Functies definiëren in JSR223 Pre-Processors. Funtie reference wordt dan opgeslagen in vars object.
Functies definiëren in setUp Thread Group. Functie reference wordt dan opgeslagen in props object.
JSR223 sampler – Script veld – Functies in props of vars – Pre-processor
Als je gebruik maakt van de JSR223 Pre-Processor kan je deze op verschillende niveaus in het Test Plan plaatsen. Ook op het hoogste niveau. Maar bedenk dan wel dat deze pre-processor uitgevoerd wordt bij elke sampler in het Test Plan dat uitgevoerd wordt. Bij heel veel samplers zal dit dan een overbodige actie zijn en zonde van de beschikbare resources. Het voordeel is dan natuurlijk wel dat je op het hoogste niveau al je functies kan definiëren wat het geheel overzichtelijker maakt.
Je kan ook de pre-processor op een lager niveau zetten. Maar als een bepaalde functie door verschillende Thread Groups gebruikt wordt, dan heb je alsnog de code op verschillende plekken staan. Dus als je dan toch de pre-processors gebruikt, zou ik dat op het hoogste niveau doen.
JSR223 sampler – Script veld – Functies in props of vars – setUp Thread Group
De andere optie die ik gaf, was het gebruik van JSR223 samplers in de setUp Thread Group. Dan heb je een mooie verzamelplaats voor je functies. De referentie naar die functies moeten dan wel opgeslagen worden in een prop.
De voordelen hiervan zijn:
Alle functies zijn mooi verzameld. (dit geldt ook voor gebruik van pre-processor)
De JSR223 sampler wordt niet bij elke sampler in Test Plan uitgevoerd.
Je kan de code voor 1 iteratie met aanroep naar verschillende functies in 1 JSR223 sampler kwijt. (dit geldt ook voor gebruik van pre-processor)
Het nadeel van deze methode is dat de functies in de setUp Thread Group “gemaakt” worden. De vars.get en vars.getObject in de functies werken niet als de functies vanuit een andere Thread Group worden aangeroepen (wat dus wel het idee is van deze methode).
Dat betekent dus dat de functies zo gemaakt moeten worden dat ze alle dynamische parameters moeten ontvangen die ze nodig hebben. Variabelen op Test Plan niveau werken hier natuurlijk wel. Maar de functie zal dan wel altijd de oorspronkelijke waarde gebruiken. Dus mocht de waarde van die var aangepast worden, dan zie je dat niet terug in de functie. vars.put of vars.putObject werken ook niet.
Dit is ook meteen een voordeel aangezien het best onoverzichtelijk kan zijn waar de verschillende vars binnen het Test Plan een waarde krijgen of waar deze waarde wordt aangepast. Dus in dat opzicht zijn het “schone” functies die niets doen met de bestaande vars.
Conclusie
Ik heb een aantal manieren beschreven waarop je zelf geschreven groovy code kan gebruiken binnen JMeter. Ik ben heel benieuwd of er nog andere manieren zijn en ook welke ervaringen jullie hiermee hebben.
Comments