Gatling vs JMeter vs The Grinder: vergelijking van testtools voor belasting
1. Inleiding
Het kiezen van het juiste gereedschap voor de klus kan ontmoedigend zijn. In deze tutorial zullen we dit vereenvoudigen door drie tools voor het testen van webapplicaties - Apache JMeter, Gatling en The Grinder - te vergelijken met een eenvoudige REST API.
2. Testhulpmiddelen laden
Laten we eerst snel wat achtergrondinformatie over elk bekijken.
2.1. Gatling
Gatling is een tool voor het testen van belasting die testscripts maakt in Scala. De recorder van Gatling genereert de Scala-testscripts, een sleutelfunctie voor Gatling. Bekijk onze Inleiding tot Gatling-tutorial voor meer informatie.
2.2. JMeter
JMeter is een testtool van Apache. Het biedt een mooie GUI die we kunnen gebruiken voor configuratie. Een unieke functie, logische controllers genaamd, geeft een grote flexibiliteit om tests in de GUI op te zetten.
Bezoek onze Inleiding tot JMeter-zelfstudie voor schermafbeeldingen en meer uitleg.
2.3. De molen
En onze laatste tool, The Grinder, biedt een meer op programmeren gebaseerde scripting-engine dan de andere twee en gebruikt Jython. The Grinder 3 heeft echter wel functionaliteit voor het opnemen van scripts.
De Grinder verschilt ook van de andere twee tools door console- en agentprocessen toe te staan. Deze functionaliteit biedt de mogelijkheid voor een agentproces, zodat de belastingstests kunnen worden opgeschaald over meerdere servers. Het wordt specifiek geadverteerd als een loadtest-tool die is ontwikkeld voor ontwikkelaars om deadlocks en vertragingen te vinden.
3. Testcase instellen
Vervolgens hebben we voor onze test een API nodig. Onze API-functionaliteit omvat:
- een beloningsrecord toevoegen / bijwerken
- bekijk een / alle beloningsrecord
- een transactie koppelen aan een klantbeloningsrecord
- bekijk transacties voor een klantbeloningsrecord
Ons scenario:
Een winkel heeft een landelijke verkoop met nieuwe en terugkerende klanten die klantenbeloningen nodig hebben om besparingen te krijgen. De beloningen-API controleert het klant-ID op klantbeloningsaccounts. Als er geen beloningsaccount bestaat, voegt u deze toe en linkt u vervolgens naar de transactie.
Hierna vragen we de transacties op.
3.1. Onze REST API
Laten we een kort overzicht van de API krijgen door enkele van de methodestubs te bekijken:
@PostMapping (path = "/ rewards / add") openbaar @ResponseBody RewardsAccount addRewardsAcount (@RequestBody RewardsAccount body) @GetMapping (path = "/ rewards / find / {customerId}") openbaar @ResponseBody Optioneel findCustomer (@PathVariable Integer customerId) @PostMapping (path = "/ transacties / add") openbaar @ResponseBody Transactie addTransaction (@RequestBody Transactie transactie) @GetMapping (path = "/ transacties / findAll / {rewardId}") openbaar @ResponseBody Herhaalbare findTransactions (@PathVariable Integer rewardId)
Let op enkele van de relaties, zoals het opvragen van transacties op basis van het belonings-ID en het verkrijgen van het beloningsaccount op basis van het klant-ID. Deze relaties dwingen enige logica en enige respons-parsing af voor het maken van ons testscenario.
De te testen applicatie maakt ook gebruik van een H2 in-memory database voor persistentie.
Gelukkig kunnen onze tools het allemaal redelijk goed aan, sommige beter dan andere.
3.2. Ons testplan
Vervolgens hebben we testscripts nodig.
Om een eerlijke vergelijking te krijgen, zullen we voor elke tool dezelfde automatiseringsstappen uitvoeren:
- Genereer willekeurige klantaccount-ID's
- Plaats een transactie
- Parseer het antwoord voor de willekeurige klant-ID en transactie-ID
- Vraag naar een klantbeloningen-account-ID met het klant-ID
- Parseer het antwoord voor de beloningsaccount-ID
- Als er geen beloningsaccount-ID bestaat, voeg er dan een toe met een bericht
- Boek dezelfde eerste transactie met bijgewerkte belonings-ID met behulp van de transactie-ID
- Query voor alle transacties op basis van beloningsaccount-ID
Laten we stap 4 voor elke tool eens nader bekijken. En zorg ervoor dat u het voorbeeld voor alle drie voltooide scripts bekijkt.
3.3. Gatling
Voor Gatling is bekendheid met Scala een zegen voor ontwikkelaars, aangezien de Gatling-API robuust is en veel functies bevat.
Gatling's API heeft een builder DSL-benadering, zoals we kunnen zien in stap 4:
.exec (http ("get_reward") .get ("/ rewards / find / $ {custId}") .check (jsonPath ("$. id"). saveAs ("rwdId")))
Van bijzonder belang is de ondersteuning van Gatling voor JSON Path wanneer we een HTTP-antwoord moeten lezen en verifiëren. Hier halen we de belonings-ID op en slaan deze op in de interne staat van Gatling.
De expressietaal van Gatling zorgt ook voor een eenvoudiger dynamische hoofdtekst van verzoeken Snaren:
.body (StringBody ("" "{" customerRewardsId ":" $ {rwdId} "," customerId ":" $ {custId} "," transactionDate ":" $ {txtDate} "}" "")). asJson)
Ten slotte onze configuratie voor deze vergelijking. De 1000 runs ingesteld als een herhaling van het hele scenario, atOnceUsers methode stelt de threads / gebruikers in:
val scn = scenario ("RewardsScenario") .repeat (1000) {...} setUp (scn.inject (atOnceUsers (100))) .protocols (httpProtocol)
Het volledige Scala-script kan worden bekeken in onze Github-opslagplaats.
3.4. JMeter
JMeter genereert een XML-bestand na de GUI-configuratie. Het bestand bevat JMeter-specifieke objecten met ingestelde eigenschappen en hun waarden, bijvoorbeeld:
Bekijk de test naam attributen, kunnen ze worden gelabeld omdat we ze herkennen in overeenstemming met de bovenstaande logische stappen. De mogelijkheid om kinderen, variabelen en afhankelijkheidsstappen toe te voegen, geeft JMeter de flexibiliteit die scripting biedt. Bovendien hebben we zelfs de scope voor onze variabelen bepaald!
Onze configuratie voor runs en gebruikers in JMeter gebruikt ThreadGroups:
100
Bekijk het hele jmx bestand als referentie. Terwijl het mogelijk is, schrijft u tests in XML als .jmx bestanden hebben geen zin met een complete GUI.
3.5. De molen
Zonder de functionele programmering van Scala en GUI ziet ons Jython-script voor The Grinder er vrij eenvoudig uit. Voeg enkele Java-systeemklassen toe en we hebben veel minder regels code.
customerId = str (random.nextInt ()); result = request1.POST ("// localhost: 8080 / transacties / add", "{" '"customerRewardsId"' ": null," '"customerId"' ":" + customerId + "," '"transactionDate"' ": null}") txnId = parseJsonString (result.getText (), "id")
Minder regels testconfiguratiecode worden echter gecompenseerd door de behoefte aan meer tekenreeksonderhoudscode, zoals het parseren van JSON-strings. Ook is de HTTPRequest-API slank qua functionaliteit.
Met The Grinder definiëren we threads, processen en runs in een extern eigenschappenbestand:
grinder.threads = 100 grinder.processen = 1 grinder.runs = 1000
Ons volledige Jython-script voor The Grinder ziet er als volgt uit.
4. Testruns
4.1. Testuitvoering
Alle drie de tools raden aan om de opdrachtregel te gebruiken voor tests met grote belasting.
Om de tests uit te voeren, gebruiken we Gatling open-source versie 3.4.0 als een zelfstandige tool, JMeter 5.3 en The Grinder versie 3.
Gatling vereist alleen wat we hebben JAVA_HOME en GATLING_HOME set. Om Gatling uit te voeren gebruiken we:
./gatling.sh
in de directory GATLING_HOME / bin.
JMeter heeft een parameter nodig om de GUI voor de test uit te schakelen, zoals gevraagd bij het starten van de GUI voor configuratie:
./jmeter.sh -n -t TestPlan.jmx -l log.jtl
Net als Gatling vereist The Grinder dat we instellen JAVA_HOME en MOLENPAD. Het heeft echter ook nog een paar eigenschappen nodig:
export CLASSPATH = / home / lore / Documents / grinder-3 / lib / grinder.jar: $ CLASSPATH export GRINDERPROPERTIES = / home / lore / Documents / grinder-3 / voorbeelden / grinder.properties
Zoals hierboven vermeld, bieden we een grinder.eigenschappen bestand voor aanvullende configuratie zoals threads, runs, processen en console-hosts.
Ten slotte bootstrappen we de console en agents met:
java -classpath $ CLASSPATH net.grinder.Console
java -classpath $ CLASSPATH net.grinder.Grinder $ GRINDERPROPERTIES
4.2. Test resultaten
Elk van de tests heeft 1000 runs uitgevoerd met 100 gebruikers / threads. Laten we enkele hoogtepunten uitpakken:
Succesvolle verzoeken | Fouten | Totale testtijd (s) | Gemiddelde reactietijd (ms) | Gemiddelde doorvoer | |
Gatling | 500000 verzoeken | 0 | 218s | 42 | 2283 aanvraag / sec |
JMeter | 499997 Verzoeken | 0 | 237s | 46 | 2101 aanvraag / s |
De molen | 499997 Verzoeken | 0 | 221s | 43 | 2280 verzoeken / sec |
De resultaten laten zien dat de 3 tools een vergelijkbare snelheid hebben, waarbij Gatling de andere 2 enigszins uitschakelt, op basis van de gemiddelde doorvoer.
Elke tool biedt ook aanvullende informatie in een vriendelijkere gebruikersinterface.
Gatling genereert aan het einde van de run een HTML-rapport dat meerdere grafieken en statistieken bevat, zowel voor de totale run als voor elk verzoek. Hier is een fragment van het testresultatenrapport:
Bij gebruik van JMeter kunnen we de GUI openen na de testrun en een HTML-rapport genereren op basis van het logbestand waar we de resultaten hebben opgeslagen:
Het JMeter HTML-rapport bevat ook een uitsplitsing van de statistieken per verzoek.
Ten slotte registreert The Grinder Console statistieken voor elke agent en voert het uit:
Hoewel The Grinder een hoge snelheid heeft, gaat dit ten koste van extra ontwikkelingstijd en minder diversiteit aan uitvoergegevens.
5. Samenvatting
Nu is het tijd om een algemene blik te werpen op elk van de loadtesttools.
Gatling | JMeter | De molen | |
Project en gemeenschap | 9 | 9 | 6 |
Prestatie | 9 | 8 | 9 |
Scriptbaarheid / API | 7 | 9 | 8 |
UI | 9 | 8 | 6 |
Rapporten | 9 | 7 | 6 |
Integratie | 7 | 9 | 7 |
Samenvatting | 8.3 | 8.3 | 7 |
Gatling:
- Solide, gepolijste loadtesttool die prachtige rapporten produceert met Scala-scripting
- Open Source- en Enterprise-ondersteuningsniveaus voor het product
JMeter:
- Robuuste API (via GUI) voor de ontwikkeling van testscripts zonder codering
- Apache Foundation-ondersteuning en geweldige integratie met Maven
De molen:
- Tool voor het testen van snelle prestaties voor ontwikkelaars die Jython gebruiken
- Schaalbaarheid tussen servers biedt nog meer mogelijkheden voor grote tests
Simpel gezegd, als snelheid en schaalbaarheid een noodzaak zijn, gebruik dan The Grinder.
Als goed uitziende interactieve grafieken helpen om een prestatieverbetering te laten zien om voor een verandering te pleiten, gebruik dan Gatling.
JMeter is de tool voor ingewikkelde bedrijfslogica of een integratielaag met veel berichttypen. Als onderdeel van de Apache Software Foundation biedt JMeter een volwassen product en een grote community.
6. Conclusie
Concluderend zien we dat de tools op sommige gebieden vergelijkbare functionaliteiten hebben, terwijl ze op andere schitteren. De juiste tool voor de juiste baan is informele wijsheid die werkt bij softwareontwikkeling.
Ten slotte zijn de API en scripts te vinden op Github.