streamalism.org

1. Bemutatkozás

A munkához megfelelő eszköz kiválasztása ijesztő lehet. Ebben az oktatóanyagban ezt egyszerűsítjük három webalkalmazás-terhelés tesztelő eszköz - az Apache JMeter, a Gatling és a The Grinder - összehasonlításával egy egyszerű REST API-val.

2. Tesztelő eszközök betöltése

Először nézzük át gyorsan a hátteret.

2.1. Gatling

A Gatling egy terhelés-tesztelő eszköz, amely teszt szkripteket hoz létre a Scalában. A Gatling felvevője létrehozza a Scala teszt szkripteket, ami a Gatling egyik legfontosabb jellemzője. További információkért tekintse meg a Bevezetés a Gatlinghoz oktatóanyagunkat.

2.2. JMeter

A JMeter az Apache által végzett terhelés tesztelő eszköz. Ez egy szép GUI-t biztosít, amelyet a kannával használunk a konfiguráláshoz. A logikai vezérlőknek nevezett egyedi szolgáltatás nagy rugalmasságot biztosít a tesztek GUI-ban történő beállításához.

Látogasson el a JMeter bemutatójához, ahol képernyőképeket és további magyarázatokat talál.

2.3. A daráló

Végső eszközünk, a The Grinder, több programozás-alapú parancsfájlmotort biztosít, mint a másik kettő, és a Jythont használja. A The Grinder 3 azonban rendelkezik funkciókkal a szkriptek rögzítéséhez.

A Grinder abban is különbözik a másik két eszköztől, hogy lehetővé teszi a konzolos és ügynöki folyamatokat. Ez a funkcionalitás lehetővé teszi az ügynökfolyamatok lehetőségét, így a terhelési tesztek több kiszolgálón terjedhetnek. Kifejezetten terhelési teszt eszközként hirdetik, amelyet a fejlesztők számára holtpontok és lassulások megtalálására fejlesztettek ki.

3. Tesztelje az eset beállítását

Ezután tesztünkhöz API-ra van szükségünk. API-funkcióink a következőket tartalmazzák:

• jutalomrekord hozzáadása / frissítése
• egy / összes jutalomrekord megtekintése
• összekapcsolja a tranzakciót az ügyfél jutalomrekordjával
• tranzakciók megtekintése az ügyfél jutalom nyilvántartásában

Forgatókönyvünk:

Egy üzlet országos akciót tart új és visszatérő vásárlókkal, akiknek megtakarításhoz vevői jutalomszámlákra van szükségük. A jutalom API ellenőrzi az ügyfél jutalom számláját az ügyfél azonosítója alapján. Ha nem létezik jutalomszámla, adja hozzá, majd kapcsolja össze a tranzakcióval.

Ezt követően lekérdezzük a tranzakciókat.

3.1. A REST API

Gyorsan kiemelhetjük az API-t, megnézve a módszer egyes elemeit:

@PostMapping (elérési út = "/ rewards / add") public @ResponseBody RewardsAccount addRewardsAcount (@RequestBody RewardsAccount body) @GetMapping (path = "/ rewards / find / {customerId}") public @ResponseBody Opcionális findCustomer (@PathVariable Integer) @PostMapping (elérési út = "/ tranzakciók / hozzáadás") public @ResponseBody Tranzakció addTransaction (@RequestBody Tranzakció tranzakció) @GetMapping (path = "/ tranzakciók / findAll / {honorId}") public @ResponseBody Iterable findTransactions (@PathVariable Integer honorId) 

Vegye figyelembe néhány összefüggést, például a tranzakciók lekérdezését a jutalomazonosító alapján és a jutalomszámla beszerzését ügyfél-azonosító szerint. Ezek a kapcsolatok némi logikát és néhány válaszelemzést kényszerítenek a teszt forgatókönyvünk létrehozásához.

A tesztelt alkalmazás H2 memóriában lévő adatbázist is használ a kitartáshoz.

Szerencsére az eszközeink mind elég jól kezelik, egyesek jobban, mint mások.

3.2. Tesztelési tervünk

Ezután teszt szkriptekre van szükségünk.

A korrekt összehasonlítás érdekében ugyanazokat az automatizálási lépéseket hajtjuk végre minden eszköznél:

1. Véletlenszerű ügyfélszámlák generálása
2. Tranzakció könyvelése
3. A véletlenszerű ügyfél-azonosító és a tranzakció-azonosító válaszának elemzése
4. Egy ügyfél lekérdezése jutalmazza a fiók azonosítóját az ügyfél azonosítóval
5. Elemezze a választ a jutalomszámla azonosítójára
6. Ha nem létezik jutalomszámla, akkor adjon hozzá egyet egy bejegyzéssel
7. Tegye közzé ugyanazt a kezdeti tranzakciót frissített jutalomazonosítóval a tranzakcióazonosító használatával
8. Minden tranzakció lekérdezése jutalomszámla azonosítóval

Vizsgáljuk meg közelebbről az egyes eszközök 4. lépését. És feltétlenül nézze meg mind a három elkészült szkript mintáját.

3.3. Gatling

A Gatling számára a Scala-val való ismerkedés áldást jelent a fejlesztők számára, mivel a Gatling API robusztus és sok funkciót tartalmaz.

A Gatling API-ja építői DSL-megközelítést alkalmaz, amint azt a 4. lépésében láthatjuk:

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

Külön figyelemre méltó Gatling támogatása a JSON Path számára, amikor el kell olvasnunk és ellenőriznünk kell egy HTTP választ. Itt felvesszük a jutalom azonosítóját, és elmentjük Gatling belső állapotába.

Ezenkívül Gatling kifejezési nyelve megkönnyíti a dinamikus kéréstestet Húrok:

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

Végül konfigurációnk ehhez az összehasonlításhoz. Az 1000 futtatás a teljes forgatókönyv ismétléseként állított be, atOnceUsers metódus állítja be a szálakat / felhasználókat:

val scn = szcenárió ("RewardsScenario") .repeat (1000) {...} setUp (scn.inject (atOnceUsers (100))) .protokollok (httpProtocol)

A teljes Scala szkript megtekinthető a Github repóban.

3.4. JMeter

A JMeter egy XML fájlt generál a GUI konfigurálása után. A fájl JMeter-specifikus objektumokat tartalmaz beállított tulajdonságokkal és azok értékeivel, például:

Nézze meg a tesztnév attribútumokat felcímkézhetjük, mivel felismerjük őket a fenti logikai lépéseknek megfelelően. Gyerekek, változók és függőségi lépések hozzáadásának rugalmassága rugalmasságot biztosít a JMeter számára, ahogyan a szkriptek is biztosítják. Továbbá még a változók hatókörét is beállítottuk!

A futtatásokra és a felhasználókra vonatkozó konfigurációnk a JMeter használatával ThreadGroups:

100

Az egész megtekintése jmx fájl referenciaként. Amíg lehetséges, teszteket írjon XML formátumban .jmx a fájloknak nincs értelme a teljes funkcionalitású GUI-val.

3.5. A daráló

A Scala és a GUI funkcionális programozása nélkül a The Grinder Jython-szkriptünk elég alaposnak tűnik. Adjon hozzá néhány Java rendszert, és sokkal kevesebb kódsorunk van.

customerId = str (random.nextInt ()); eredmény = request1.POST ("// localhost: 8080 / tranzakciók / add", "{" "" customerRewardsId "" ": null," "" customerId "" ":" + customerId + "," ""actionDate" ' ": null}") txnId = parseJsonString (result.getText (), "id")

A tesztbeállítási kód kevesebb sorát azonban kiegyenlíti a több karaktersorozat-karbantartási kód, például a JSON-karakterláncok elemzése szükségessége. Ezenkívül a HTTPRequest API karcsú a funkcionalitás terén.

A The Grinder segítségével szálakat, folyamatokat és futási értékeket határoz meg egy külső tulajdonságfájlban:

daráló.szálak = 100 daráló.folyamatok = 1 daráló.fut = 1000

A The Grinder teljes Jython-szkriptje így fog kinézni.

4. Tesztfuttatások

4.1. Teszt végrehajtása

Mindhárom eszköz a parancssor használatát javasolja nagy terheléses tesztekhez.

A tesztek futtatásához a Gatling nyílt forráskódú 3.4.0-s verzióját használjuk önálló eszközként, a JMeter 5.3-at és a The Grinder 3. verzióját.

A gatlinghoz csak arra van szükségünk, amink van JAVA_HOME és GATLING_HOME készlet. A Gatling végrehajtásához a következőket használjuk:

./gatling.sh

a GATLING_HOME / bin könyvtárban.

A JMeter-nek szüksége van egy paraméterre a GUI letiltásához a teszthez, amint a GUI konfigurálásakor elindul:

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

Gatlinghoz hasonlóan a Grinder is megköveteli, hogy mi állítsuk be JAVA_HOME és GRINDERPATH. Ehhez azonban még néhány tulajdonságra van szüksége:

export CLASSPATH = / home / lore / Documents / grinder-3 / lib / grinder.jar: $ CLASSPATH export GRINDERPROPERTIES = / home / lore / Documents / grinder-3 / példa / grinder.properties

Mint fent említettük, a daráló.tulajdonságok fájl további konfigurációkhoz, például szálakhoz, futtatásokhoz, folyamatokhoz és konzol gazdagépekhez.

Végül a konzolt és az ügynököket indítjuk:

java -classpath $ CLASSPATH net.grinder.Console

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

4.2. Vizsgálati eredmények

Mindegyik teszt 1000 futást futtatott 100 felhasználó / szál mellett. Csomagoljuk ki a legfontosabb eseményeket:

Az eredmények azt mutatják, hogy a 3 eszköz hasonló sebességgel rendelkezik, Gatling az átlagos áteresztőképesség alapján kissé kiszúrja a másik kettőt.

Minden eszköz további információkat nyújt egy barátságosabb felhasználói felületen is.

A Gatling a futtatás végén generál egy HTML jelentést, amely több grafikont és statisztikát tartalmaz a teljes futásról és az egyes kérésekről. Itt található a teszt eredményjelentésének részlete:

A JMeter használatakor a tesztfutás után megnyithatjuk a GUI-t, és a naplófájl alapján HTML jelentést készíthetünk ahol elmentettük az eredményeket:

A JMeter HTML jelentés tartalmazza a statisztikák bontását kérésenként.

Végül a Grinder Console rögzíti az egyes ügynökök statisztikáit és futtatja:

Bár a Grinder nagy sebességű, további fejlesztési idő és a kimeneti adatok kevesebb változatosságának árával jár.

5. Összefoglalás

Itt az ideje, hogy átfogóan szemügyre vegye az egyes terhelésvizsgálati eszközöket.

Gatling:

• Szilárd, csiszolt terhelés-tesztelő eszköz, amely gyönyörű jelentéseket készít a Scala parancsfájlokkal
• A termék nyílt forráskódú és vállalati támogatási szintjei

JMeter:

• Robusztus API (GUI-n keresztül) a teszt szkriptek fejlesztéséhez kódolás nélkül
• Apache Alapítvány támogatása és nagyszerű integrációja a Maven-nel

A daráló:

• Gyors teljesítményteszt-tesztelő eszköz a Jythont használó fejlesztők számára
• A szerverek közötti skálázhatóság még nagyobb lehetőséget jelent a nagy tesztek számára

Egyszerűen fogalmazva, ha szükség van a sebességre és a méretezhetőségre, akkor használja a The Grinder-t.

Ha a nagyszerű interaktív grafikonok segítenek a teljesítménynövekedésben a változás mellett érvelni, akkor használja a Gatling-ot.

A JMeter a bonyolult üzleti logika vagy a sok üzenettípussal rendelkező integrációs réteg eszköze. Az Apache Software Foundation részeként a JMeter érett terméket és nagy közösséget biztosít.

6. Következtetés

Összegzésként azt látjuk, hogy az eszközök bizonyos területeken összehasonlítható funkcionalitással bírnak, míg másokban ragyognak. A megfelelő munka a megfelelő munkához a köznyelvi bölcsesség, amely a szoftverfejlesztésben működik.

Végül az API és a szkriptek megtalálhatók a Githubon.