streamalism.org

1. Introduksjon

Å velge riktig verktøy for jobben kan være skremmende. I denne veiledningen forenkler vi dette ved å sammenligne tre verktøy for testing av nettapplikasjoner - Apache JMeter, Gatling og The Grinder - mot et enkelt REST API.

2. Lasttestverktøy

La oss først gjennomgå litt bakgrunn om hver.

2.1. Gatling

Gatling er et lastetestingverktøy som lager testskripter i Scala. Gatlings opptaker genererer Scala-testskriptene, en nøkkelfunksjon for Gatling. Ta en titt på Intro to Gatling-veiledningen for mer informasjon.

2.2. JMeter

JMeter er et lastetestingverktøy fra Apache. Det gir en fin GUI som vi bruker kan for konfigurasjon. En unik funksjon kalt logikkontrollere gir stor fleksibilitet til å sette opp tester i GUI.

Besøk Intro to JMeter tutorial for skjermbilder og mer forklaring.

2.3. Kvernen

Og vårt siste verktøy, The Grinder, gir en mer programmeringsbasert skriptmotor enn de to andre og bruker Jython. Imidlertid har The Grinder 3 funksjonalitet for opptak av manus.

Grinder skiller seg også fra de to andre verktøyene ved å tillate konsoll- og agentprosesser. Denne funksjonaliteten gir muligheten for en agentprosess slik at belastningstestene kan skaleres opp på tvers av flere servere. Det er spesielt annonsert som et lastetestverktøy som er utviklet for utviklere for å finne fastlåser og forsinkelser.

3. Test saksoppsett

Deretter trenger vi en API for testen vår. Vår API-funksjonalitet inkluderer:

• legge til / oppdatere en belønningspost
• se en / alle belønningsposter
• koble en transaksjon til en kundebelønningspost
• se transaksjoner for en kundebelønningspost

Vårt scenario:

En butikk har et landsdekkende salg med nye og tilbakevendende kunder som trenger kundebelønningskontoer for å få besparelser. Belønnings-API-et sjekker etter kundebelønningskonto etter kunde-ID. Hvis det ikke finnes noen belønningskonto, kan du legge den til og deretter koble til transaksjonen.

Etter dette spør vi om transaksjonene.

3.1. Vår REST API

La oss få et raskt høydepunkt av API-et ved å se på noen av metodestubber:

@PostMapping (path = "/ rewards / add") offentlig @ResponseBody RewardsAccount addRewardsAcount (@RequestBody RewardsAccount body) @GetMapping (path = "/ rewards / find / {customerId}") public @ResponseBody Valgfri findCustomer (@PathVariable Integer customerId) @PostMapping (sti = "/ transaksjoner / legg til") offentlig @ResponseBody Transaksjon addTransaction (@RequestBody Transaksjonstransaksjon) @GetMapping (sti = "/ transaksjoner / findAll / {rewardId}") offentlig @ResponseBody Iterabel findTransactions (@PathVariable Integer rewardId) 

Legg merke til noen av forholdene som å spørre etter transaksjoner etter belønnings-ID og få belønningskontoen etter kunde-ID. Disse forholdene tvinge litt logikk og noe responsparsing for å lage testscenariet vårt.

Søknaden under test bruker også en H2-minne-database for utholdenhet.

Heldigvis håndterer verktøyene våre ganske bra, noen bedre enn andre.

3.2. Testplanen vår

Deretter trenger vi testskript.

For å få en rettferdig sammenligning vil vi utføre de samme automatiseringstrinnene for hvert verktøy:

1. Generer tilfeldige ID-er for kundekontoer
2. Legg ut en transaksjon
3. Analyser svaret for tilfeldig kunde-ID og transaksjons-ID
4. Spørring etter en kunde belønner konto-ID med kunde-ID
5. Analyser svaret for belønningskonto-ID
6. Hvis det ikke finnes noen ID for belønningskontoer, kan du legge til en med et innlegg
7. Legg ut samme innledende transaksjon med oppdatert belønnings-ID ved hjelp av transaksjons-ID
8. Spørring for alle transaksjoner etter belønningskonto-ID

La oss se nærmere på trinn 4 for hvert verktøy. Sørg for å sjekke ut prøven for alle de tre ferdige skriptene.

3.3. Gatling

For Gatling gir fortrolighet med Scala en velsignelse for utviklere siden Gatling API er robust og inneholder mange funksjoner.

Gatlings API tar en byggherre DSL-tilnærming, som vi kan se i trinn 4:

.exec (http ("get_reward") .get ("/ rewards / find / $ {custId}") .check (jsonPath ("$. id"). saveAs ("rwdId"))) 

Av spesiell oppmerksomhet er Gatlings støtte for JSON Path når vi trenger å lese og verifisere et HTTP-svar. Her henter vi belønnings-IDen og lagrer den i Gatlings interne tilstand.

Gatlings uttrykksspråk gir også lettere dynamisk forespørsel Strenger:

.body (StringBody ("" "{" customerRewardsId ":" $ {rwdId} "," customerId ":" $ {custId} "," transactionDate ":" $ {txtDate} "}" "")). asJson) 

Til slutt vår konfigurasjon for denne sammenligningen. De 1000 løpene er satt som en repetisjon av hele scenariet, påEn gangBrukere metoden setter trådene / brukerne:

val scn = scenario ("RewardsScenario"). repeat (1000) {...} setUp (scn.inject (atOnceUsers (100))) .protocols (httpProtocol)

Hele Scala-skriptet kan vises på Github-repoen vår.

3.4. JMeter

JMeter genererer en XML-fil etter GUI-konfigurasjonen. Filen inneholder JMeter-spesifikke objekter med angitte egenskaper og deres verdier, for eksempel:

Sjekk ut testnavn attributter, kan de merkes når vi gjenkjenner dem som samsvarer med de logiske trinnene ovenfor. Evnen til å legge til barn, variabler og avhengighetstrinn gir JMeter fleksibilitet slik skripting gir. Videre setter vi til og med muligheten for variablene våre!

Vår konfigurasjon for kjøringer og brukere i JMeter-bruk Trådgrupper:

100

Se hele jmx filen som referanse. Mens det er mulig, skriver du tester i XML som .jmx filer gir ikke mening med en fullverdig GUI.

3.5. Kvernen

Uten funksjonell programmering av Scala og GUI, ser Jython-skriptet til The Grinder ganske grunnleggende ut. Legg til noen Java-klasser, og vi har mange færre linjer med kode.

customerId = str (random.nextInt ()); resultat = forespørsel1.POST ("// localhost: 8080 / transaksjoner / add", "{" '"customerRewardsId"' ": null," '"customerId"' ":" + customerId + "," '"transactionDate"' ": null}") txnId = parseJsonString (result.getText (), "id")

Imidlertid balanseres færre linjer med testoppsettkode av behovet for mer strengvedlikeholdskode, for eksempel analyse av JSON-strenger. HTTPRequest API har også liten funksjonalitet.

Med The Grinder definerer vi tråder, prosesser og kjører verdier i en ekstern egenskapsfil:

kvern.tråder = 100 kvern.prosesser = 1 kvern. kjører = 1000

Vårt fullstendige Jython-skript for The Grinder vil se slik ut.

4. Testkjøring

4.1. Testutførelse

Alle de tre verktøyene anbefaler å bruke kommandolinjen til store belastningstester.

For å kjøre testene bruker vi Gatling open source versjon 3.4.0 som et frittstående verktøy, JMeter 5.3 og The Grinder versjon 3.

Gatling krever bare at vi har JAVA_HOME og GATLING_HOME sett. For å utføre Gatling bruker vi:

./gatling.sh

i GATLING_HOME / bin-katalogen.

JMeter trenger en parameter for å deaktivere GUI for testen slik du blir bedt om når du starter GUI for konfigurasjon:

./jmeter.sh -n -t TestPlan.jmx -l log.jtl

I likhet med Gatling krever The Grinder at vi setter JAVA_HOME og GRINDERPATH. Imidlertid trenger det et par flere egenskaper også:

eksporter CLASSPATH = / home / lore / Documents / grinder-3 / lib / grinder.jar: $ CLASSPATH export GRINDERPROPERTIES = / home / lore / Documents / grinder-3 / examples / grinder.properties

Som nevnt ovenfor, gir vi en kvern. eiendommer fil for ytterligere konfigurasjon, for eksempel tråder, kjøringer, prosesser og konsollverter.

Til slutt starter vi konsollen og agenter med:

java -classpath $ CLASSPATH net.grinder.Console

java -classpath $ CLASSPATH net.grinder.Grinder $ GRINDERPROPERTIES

4.2. Testresultater

Hver av testene kjørte 1000 løp med 100 brukere / tråder. La oss pakke ut noen av høydepunktene:

Resultatene viser at de tre verktøyene har lignende hastighet, med Gatling som svinger litt ut de andre 2, basert på gjennomsnittlig gjennomstrømning.

Hvert verktøy gir også tilleggsinformasjon i et vennligere brukergrensesnitt.

Gatling vil generere en HTML-rapport på slutten av løpet, som inneholder flere grafer og statistikk, for den totale løpet samt for hver forespørsel. Her er et utdrag av testresultatrapporten:

Når du bruker JMeter, kan vi åpne GUI etter testkjøringen og generere en HTML-rapport basert på loggfilen hvor vi lagret resultatene:

JMeter HTML-rapporten inneholder også en oversikt over statistikken per forespørsel.

Til slutt registrerer The Grinder Console statistikk for hver agent og kjører:

Mens The Grinder er høyhastighets, koster det ekstra utviklingstid og mindre mangfold av utdata.

5. Sammendrag

Nå er det på tide å ta et samlet blikk på hvert av lastetestverktøyene.

Gatling:

• Solid, polert belastningstestverktøy som gir vakre rapporter med Scala-skripting
• Støttenivåer for åpen kildekode og bedrift for produktet

JMeter:

• Robust API (gjennom GUI) for utvikling av testskript uten koding nødvendig
• Apache Foundation Support og god integrasjon med Maven

Kvernen:

• Raskt verktøy for belastningstesting for utviklere som bruker Jython
• Skalerbarhet på tvers av servere gir enda større potensial for store tester

Enkelt sagt, hvis hastighet og skalerbarhet er et behov, så bruk The Grinder.

Hvis flotte interaktive grafer hjelper til med å vise en ytelsesgevinst for å argumentere for en endring, så bruk Gatling.

JMeter er verktøyet for komplisert forretningslogikk eller et integreringslag med mange meldingstyper. Som en del av Apache Software Foundation tilbyr JMeter et modent produkt og et stort fellesskap.

6. Konklusjon

Avslutningsvis ser vi at verktøyene har sammenlignbare funksjoner på noen områder mens de skinner i andre. Det riktige verktøyet for riktig jobb er dagligdags visdom som fungerer innen programvareutvikling.

Til slutt finner du API og skript på Github.