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:

  1. Genereer willekeurige klantaccount-ID's
  2. Plaats een transactie
  3. Parseer het antwoord voor de willekeurige klant-ID en transactie-ID
  4. Vraag naar een klantbeloningen-account-ID met het klant-ID
  5. Parseer het antwoord voor de beloningsaccount-ID
  6. Als er geen beloningsaccount-ID bestaat, voeg er dan een toe met een bericht
  7. Boek dezelfde eerste transactie met bijgewerkte belonings-ID met behulp van de transactie-ID
  8. 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 verzoekenFoutenTotale testtijd (s)Gemiddelde reactietijd (ms) Gemiddelde doorvoer
Gatling500000 verzoeken0218s422283 aanvraag / sec
JMeter499997 Verzoeken0237s462101 aanvraag / s
De molen499997 Verzoeken0221s432280 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.

GatlingJMeterDe molen
Project en gemeenschap996
Prestatie989
Scriptbaarheid / API798
UI986
Rapporten976
Integratie797
Samenvatting8.38.37

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.


$config[zx-auto] not found$config[zx-overlay] not found