8. fejezet - Tesztelés támogatás

A tesztelés automatizálására számos alkalmazás létezik, különböző céllal és különböző megvalósítással. Mi most az Apache JMeter alkalmazás elvét, használatát fogjuk bemutatni. A webalkalmazások elterjedése után azok tesztelése elengedhetetlen lehetőleg a végfelhasználói környezetben. A webalkalmazás tesztelése nem csak a helyesség ellenőrzésében merül ki, hanem életszerű stressz tesztet, teljesítmény tesztet is kell futtatni. A Jmeter egy széles körben használható teszt alkalmazás, ami könnyen kezelhető és hatékony. Segítségével grafikus felületen megtekinhetjük az eredményeket.

8.1. JMeter

Egy web alkalmazás terheléses teszteléséhez speciális szoftverre van szükség, hacsak nem áll az adminisztrátor rendelkezésére web böngészővel és sok felesleges idővel ellátott emberek sokasága.

Számos terheléses tesztet végző alkalmazás érhető el, beleértve a nyílt forráskódú szoftvereket és kereskedelmi csomagokat (néhány megfizethető és néhány különösen drága), sőt néhányan (általában helytelenül) megírják saját tesztelőjüket. Ebben a fejezetben, mint a terheléses tesztelés megoldásaként, az Apache projekt JMeter nevű alkalmazását mutatjuk be. A JMeter az egyik elérhető és a legkifinomultabb megoldás. FTP, JDBC adatforrások és Java objektumok terheléses tesztelésére is alkalmas.

A JMeter számos olyan összetevővel rendelkezik, melynek segítségével még valószerűbben szimulálhatjuk a felhasználókat, ezáltal jobb tesztelést elérve:

  1. „Timer” (Időzítő): Az időzítő segítségével lehetőségünk van a felhasználói kérések közé késleltetést beiktatni. A JMeter támogatja a konstans időzítést (a kérések között konstans késleltetés), a konstans áteresztőképességű időzítést (percenkénti konstans kérésszám) csakúgy, mint a véletlenszerű időzítést, mellyel web oldalunk valós, véletlenszerű forgalma szimulálható.

  2. „Logic Controller” (Logikai vezérlő): A végrehajtási folyamatot vezérli.

  3. „Assertions” (Állítások): A web szervertől visszaérkező adatokat ellenőrzi.

  4. „HTTP proxy server” (HTTP proxy szerver): A proxy szerver képes eltárolni a böngésző és a szerver közötti forgalmat, és később ezt, mint teszt esetet felhasználhatjuk.

  5. „Distributed load testing” (Elosztott terheléses tesztelés): A JMeter szerver módban is képes futni több JMeter kliens irányításával, így elosztott terheléses tesztelést is végezhetünk, különösen, ha a szerver teljesítményét teszteljük a fizikai távolságra nézve.

8.1.1. A JMeter telepítése és futtatása

A JMeter honlapjáról http://jakarta.apache.org/jmeter/ letölthető annak legújabb verziója (GZIP, ZIP formátumban). Ebben a fejezetben a JMeter 2.2-es verziójával foglalkozunk. A telepítéshez egyszerűen csak tömörítsük ki a fájlokat (java alkalmazás). A JMeter három módban futtatható:

  1. Önálló GUI alkalmazásként

  2. Nem interaktívan, parancssorból, vagy Ant szkriptet használva

  3. Szerven módban elosztott teszteléshez

Általában önálló alkalmazásként futtatjuk. A JMeter elindításához a bin könyvtárban lévő jmeter.bat fájlt (Windows alatt) vagy a jmeter shell szkriptet (Linux vagy Unix alatt) indítsuk el.

A 20-1. ábrán látható az üdvözlő képernyő.

8.1.2. Teszt eset fogalma, készítése és értelmezése JMeter segítségével

20-1. ábra: A JMeter interfésze.

A JMeter felhasználói felületének bal oldali paneljában fa szerkezetben láthatjuk a hozzáadott elemeket és eseményeket, a jobb oldali panelban a hozzáadott elemek kimenete látható, és konfigurálása végezhető el. Minden JMeter munkafolyamat központja a teszt eset, amely a végrehajtandó feladatokat tartalmazza. A teszt eset a teszt fa gyökéreleme. Teszt esethez a helyi menüből (jobb klikk a csomóponton) adhatunk hozzá elemeket az „Add” menüpontot választva.

Az üdvözlő képernyő másik eleme a „workbench” (munkapad), amely a teszt esethez még hozzá nem adott teszt elemeket tartalmazza. A munkapadon kísérletezhetünk a konfigurációkkal, mozgathatjuk azokat a különböző teszt esetek között.

A speciális beállítási lehetőségek előtt a lehető legegyszerűbb teszt eseten keresztül fogjuk bemutatni egy HTTP szerver tesztelését. Minden teszt eset első eleme egy „thread group” (szálak csoportja). A „thread group” nem más, mint elemek kollekciója. Minden egyes „thread group” Java szálak saját halmazával és különböző konfigurációval rendelkezik.

A bal oldali panelben a teszt eseten jobb egérgombbal kattintva, és az „Add” menüpontot választva, hozzáadhatunk egy „thread group” elemet a teszt esethez. Ezek után a bal oldali panelben a „thread group” elemet kiválasztva, a jobb oldali panelben végezhetjük el a konfigurálást (lásd 20-2. ábra). Most még tartsuk meg az alapbeállításokat.

20-2. ábra: „Thread Group” hozzáadása.

A következő konfigurálási beállítások érhetőek el:

  1. „Name” (Név): A nevet hagyhatjuk változatlanul egy egyszerű teszt esetnél, de ha több „thread group” elemünk is van, érdemes elnevezni őket, hogy később könnyebben meg tudjuk különböztetni azokat.

  2. „Number of Threads” (Szálak Száma): A végrehajtás során felhasználható szálak száma. Minden szál egy további felhasználónak felel meg, melyek egyidejűleg hajtják végre a csoporthoz rendelt feladatot.

  3. „Ramp-Up Period” (Időköz): A JMeter egy „thread group” indulásakor egy szálat indít el, és a folyamat során egyenletesen indítja el az újabb szálakat "időköz" késleltetéssel, amíg el nem éri a szálak számánál megadott maximális értéket.

  4. „Loop Count” (Ismétlések Száma): Itt megadható, hogy a „thread group”-ban levő fonál hányszor futtassa le a hozzá rendelt elemeket. Az alapbeállítás egy. Ha a „Forever” (végtelen) lehetőséget választjuk, a tesztelési terv elemeit addig futtatja újra és újra a „thread group”, amíg le nem állítjuk.

  5. „Scheduler” (Ütemező): Az indulás és befejezés dátumát és időpontját állíthatjuk be. Ilynekor nem kell kézzel leállítanunk.

Ha például a szálak számát 200-ra (200 szimulált felhasználó), az időközt egy másodpercre és az ismétlések számát 2-re állítjuk (minden kérés kétszer kerül elküldésre), akkor összesen négyszáz kérést fog leküldeni az eszköz, amiből 200-200 közel egy isdőben fog indulni.

Az előzőekben hozzáadott „thread group” elemet fogjuk használni. A „thread group” ikonján jobb egérgombbal kattintva, a helyi menüből az „Add”, utána a „Sampler”, majd a „HTTP Request” menüpontokat választva, a 20-3. ábrán látható eredményhez jutunk.

20-3. ábra: „HTTP Request” elem hozzáadása.

A bal oldali panelről a „HTTP Request” elemet kiválasztva, a jobb oldali panelben jelenik meg az előzőeknél összetettebb konfigurálási panel (20-4. ábra).

20-4. ábra: A „HTTP Request” elem konfigurációs képernyője.

Ezen a képernyőn a szerver beállítások érhetőek el, melyek közül néhány jelentése nyilvánvaló. A kevésbé egyértelmű beállítások:

  1. „Protocol” (Protokoll): Értéke HTTP vagy HTTPS lehet.

  2. „Method” (Módszer): A HTTP kérésnél használt módszer megadása (GET, POST, HEAD, PUT, OPTIONS, DELETE, TRACE). Web alkalmazás tesztelésénél általában a GET vagy a POST módszert használjuk a kért oldaltól függően.

  3. „Path” (Útvonal): A tesztelni kívánt oldal URI-je (Universal Resource Identifier). GET módszer esetében a paramétereket (például: ?name=ben) nem ebben a mezőben kell megadni.

  4. „Follow Redirects” (Átírányítás): A web szerver speciális HTTP választ adhat vissza, melyben másik URL-re irányítja a web böngészőt (a HTML és egyéb típusú tartalmakkal ellentétben). A böngészők általában a felhasználó által észrevehetetlenül követik az átirányítást. Általában engedélyezzük.

  5. „Use KeepAlive” (Kapcsolat fenntartása): A legtöbb web szerver és böngésző támogatja, hogy a köztük lévő kapcsolat ne szakadjon meg azonnal, amint a szerver válasza megérkezik a böngészőhöz, hanem egy rövid ideig még fenntartják azt, az ugyanazon böngészőtől érkező esetleges további kérések érdekében („keep-alive” kapcsolat). Terheléses tesztelés esetében érdemes ezt a lehetőséget választanunk.

  6. „Send Parameters with the Request” (Paraméterek): A GET és POST paramétereket lehet megadni. Az Encode oszlopban jelezhetjük, hogy a névre és az értékre kell-e HTTP kódolást alkalmazni. Például az & karakter és a szóköz kódolása szükséges. Az Include Equals oszlopban jelezhetjük, ha azon ritka esetről van szó, mikor a web alkalmazás nem számít rá, hogy a név és az érték között egyenlőség jel (=) van.

  7. „Filename” (Fájlnév): HTTP POST kérés esetében lehetőség van fájl feltöltésre is. Ebben a mezőben megadható, melyik fájl kerüljön feltöltésre.

  8. „Value for „name” attribute” (Név attribútum): A fájlok kulcs-érték párként kerülnek feltöltésre. Ezt a mezőt használhatjuk a kulcs nevének megadására, mellyel a továbbiakban a feltöltött fájlra hivatkozunk.

  9. „MIME type” (MIME típus): A feltöltött fájl típusát adhatjuk meg. Például HTTP fájl esetében text/html, Adobe Acrobat fájl esetében application/pdf a megfelelő MIME típus.

  10. „Retrieve All Embedded Resources from HTML Files” (Beágyazott fájlok): Egy web böngészőnek az eredeti HTML kéréstől külön kell kérnie a HTML oldal által hivatkozott képeket és egyéb tartalmakat (például CSS oldalak).

Feltételezve, hogy a Tomcat ugyanarra a gépre van telepítve, mint amelyiken a JMeter-t futtatjuk, a „Server Name or IP” (Szerver Neve vagy IP Száma) értéke localhost, a „Port Number” (Port Szám) értéke 8080 (alapértelmezett HTTP port Tomcat esetében) legyen, az útvonal pedig az /examples/servlets/servlet/HelloWorldExample értékre legyen beállítva. Ez az elérési útvonala a Tomcat által biztosított egyik példa szervletnek. Ha a JMeter és a szerver nem egy fizikai gépen futnak, akkor egyszerűen be kell állítani a megfelelő szerver IP-t vagy hosztot. Minden más paramétert hagyjunk változatlanul. A befejezett konfiguráció a 20-4. ábrán látható.

A korábbi konfigurációs beállítások elvégzése után utasíthatjuk a JMeter-t, hogy kérésekkel bombázza a web alkalmazást. A „Run” menüből a „Start” menüpontot kiválasztva indíthatjuk el a tesztelést. Első alkalommal a JMeter felajánlja a teszt elmentését.

Mielőtt azonban a tesztet futtatnánk, még néhány beállítást el kell végeznünk, hogy a teszt eredményét meg is tudjuk tekinteni.

A JMeter tervezésekor szempont volt, hogy a teszt eset futtatása elkülönüljön a tesztelési eredmények begyűjtésétől és elemzésétől. Ezt az „Observer” (Megfigyelő), vagy más néven „Event Listener desing pattern” (Esemény Figyelő Tervezési Minta) valósítja meg. Az utóbbi elnevezés tükrözi a JMeter felhasználói interfészén használt terminológiát. Az tevékenységek végrehajtásáért a „Controllers” (Vezérlő), míg az azokra való reagálásért a „listener” (Figyelő) a felelős. Tehát ahhoz, hogy a teszt eset eredményeit megtekinthessük, egy „listener” elemet kell használnunk.

A „thread group” ikonjára jobb egérgombbal kattintva, az „Add”, majd a „Listener” menüpontokat választva, egy „listener”-t adhatunk hozzá a teszt esethez. Válasszuk a „View Results Tree” beépített „listener”-t.

A bal oldali panelben kiválasztva a „View Results Tree” ikont, a jobb oldali panelben megjelenik a kimeneti képernyője. A „listener” nem igényel konfigurálási beállításokat. „View Results Tree” „listener”-rel futtatva a teszt esetet, minden válasz azonnal látható, amint megérkezett. A jobb oldali panelben a fa szerkezet egy elemét kiválasztva, a szerver válasza a „Response Data” fül alatt látható a jobb oldali panel alsó részében.

Mielőtt elindítanánk a tesztet, a jelenlegi JMeter konfigurációt mentsük el a bal oldali panelben a teszt eset ikonra jobb egérgombbal kattintva, majd a „Save As” menüpontot választva.

Az első teszt eset készen áll a futtatásra. A menüsorból a „Run”, majd a „Start” lehetőséget választva indíthatjuk el a tesztet, de előtte kattintsunk a „View Results Tree” elemre. A teszt indítása után a jobb oldali panelben a fa gyökere könyvtár ikonná alakul át, ahogy a teszt eredmények elkezdenek érkezni. A gyökérre duplán kattintva látható válnak az egyedi teszt eredmények. Az alsó panelben az eredmények valamelyikére kattintva megjelennek a válasz adatok, úgy mint letöltése idő (ezred másodpercben), HTTP válasz kódja és szövege.

A 20-5. ábrán egy elkészített teszt eset látható, a „View Results Tree” elem kiválasztva.

20-5. ábra: Egy teszt eredményének megjelenítése.

Mivel a szálak és az ismétlések számát is egyre állítottuk, így a teszt pontosan egyszer futott le. A „thread group” konfigurálásánál megadhatunk nagyobb értékeket újabb futtatáshoz, ezeket a beállításokat a későbbi példákban még használni fogjuk.

8.1.3. JMeter eszközök

A „View Results Tree” képernyőjén manuálisan, egyesével végigkattintgatni az egyes eredményeket, nem valami hatékony mód a terheléses tesztelés adatainak elemzésére. Mindazonáltal az előző példában egy egyszerű módszert mutattunk be, melynek nyilvánvalóan vannak korlátai. Szerencsére a JMeter számos eszközzel támogatja az adatgyűjtést és elemzést. A következők a JMeter főbb eszközei:

  1. „Timer” (Időzítő)

  2. „Listener” (Figyelő)

  3. „Logic Controller” (Logikai vezérlő)

  4. „Sampler” (Minta vételező)

  5. „Config Element” (Konfigurációs beállítások)

A következő bekezdésekben ezen eszközök HTTP-hez kapcsoló főbb jellemzőit vizsgáljuk meg.

Timer

Az előző példában egy szálat használtunk, és egy kérést küldtünk a szervernek a teszt befejezése előtt. Ha az ismétlés számot egy nagyobbra állítottuk volna be a „thread group” konfigurációjánál, akkor annyi kéréssel bombáztuk volna egymás után a szervert. A valóságban a web szerver használat azonban nem ennyire egyszerű. Néha több kérés érkezik egyszerre, és a kérések között eltelt idő véletlenszerű.

A kérések valószerűbb szimulálásához „timer” elemet adhatunk hozzá a „thread group” elemhez. A „timer” elemek segítségével beállítható az egyes szálak kéréseinek gyakorisága és sebessége. A JMeter által támogatott „timer” típusok:

  1. „BeanShell timer” (BeanShell Időzítő)

  2. „Constant throughput timer” (Konstans Áteresztőképességű Időzítő)

  3. „Constant timer” (Konstans Időzítő)

  4. „Synchronizing timer” (Szinkronizáló Időzítő)

  5. „Gaussian random timer” (Gauss-véletlen Időzítő)

  6. „Uniform random timer” (Véletlen Időzítő)

A legtöbb „timer” két kategóriába sorolható: véletlen és konstans.

A „Constant timer” és a „Constant throughput timer” konstans „timer”- típusok. A „Constant timer” egy konfigurálható és konstans késleltetést illeszt be az egyes szálak által elküldött kérések közé. A késleltetést ezred másodpercben kell megadni, az alapértelmezett értek 300. A „Constant throughput timer” segítségével viszont elkerülhetjük az ezred másodpercekkel való bajlódást, helyette beállíthatjuk, hogy az egyes szálak percenként mennyi kérést generáljanak. Az alapértelmezett érték 60 kérés percenként.

Véletlen „timer” típus a „Uniform random timer” és a „Gaussian random timer”. Ezen „timer” típusok véletlenszerűen kiszámított késleltetéseket illesztenek be az egyes szálak által generált kérések közé, így sokkal jobban szimulálják a valós világ forgalmát. A „Uniform random timer” egy valóban véletlen késleltetési időközt ad hozzá a konfigurálható konstans késleltetéshez, amíg a „Gaussian random timer” statisztikai számításokat használva pszeudó-véletlen késleltetést generál. Mindkét véletlen típusú „timer” egy konfigurálható, konstans időközhöz adja hozzá az általa generált véletlen késleltetést.

A „Synchronizing timer” és a „BeanShell timer” az előző kategóriák egyikébe sem sorolható.

A „Synchronizing timer” segítségével felfüggeszthető a szálak működése, amíg a felfüggesztett szálak száma egy bizonyos (előre beállított) nagyságot el nem ér, majd egyszerre engedhetjük el valamennyi szálat. Ez a fajta „timer” jól használható, ha a teszt esetünk egy adott pontján egy előre meghatározott nagyságú terhelésre van szükségünk.

Az „BeanShell timer”, melynek segítségével BeanShell szkriptet írhatunk a késleltetés generálására. A BeanShell a JRE-n belül futó szkript nyelv.

A „thread group” ikonján jobb egérgombbal kattintva, a helyi menüből az „Add”, majd a „Timer” menüpontot választva, a kívánt típusú „timer” elemet adhatjuk hozzá a teszt esethez. Egy „thread group” elemhez hozzáadott „timer” hatással van a teljes „thread group”-ra, de nincs semmilyen hatással a társ „thread group” elemekre. Egy „thread group” elemhez több „timer”-t hozzáadva mellékhatások várhatóak.

Listener

Ahogy korábban már említettük, a „listener” segítségével követhetjük nyomon a kéréseket és reagálhatunk azok eredményeire. A korábbi példában a „View Results Tree” „listener” alkalmazásával kerültek bemutatásra a szerver által visszaküldött adatok, úgy mint a válasz idő, HTTP válasz kódja és szövege.

A „listener” csak azon „thread group” tevékenységét figyeli, melyhez hozzáadtuk. Például, tekintsük az A és B „thread group”-t. A B-hez hozzáadott „listener” teljesen figyelmen kívül hagyja, mi történik az A hatáskörében. A következő táblázatban találhatóak a JMeter által alapértelmezésben támogatott „listener” típusok.

„Listener”

Leírás

„Assertion Results” (Állítás Nézet).

A „thread group” „Assertion” elemeinek kimenetét ábrázolja.

„Graph Full Results” (Teljes Grafikon Nézet).

Egy teljes grafikon segítségével ábrázolja a kérések válasz idejét.

„Graph Results” (Grafikon Nézet).

Egyszerű grafikon nézet, a „thread group” minden kérés adatait, válasz idejének átlagát és szórását ábrázolja.

„Simple Data Writer” (Egyszerű Adatíró).

Fájlba írja a tesztelt URL-eket és azok válasz idejét későbbi elemzés céljából.

„View Results in Table” (Táblázat Megjelenítés).

Táblázatba rendezve, valós időben tekinthetjük meg a teszt eredményeket.

„View Results Tree” (Fa Megjelenítés).

Fa struktúrába rendezve, valós időben tekinthetjük meg a teszt eredményeket.

„Aggregate Report” (Összegző Jelentés).

Az egyes erőforrásokról jelenít meg összegző információkat, úgy mint kérések száma, átlagos válasz idő, stb.

„Spline Visualizer” (Görbe Megjelenítő).

A teszt eset futása alatt grafikon nézetben tekinthetjük meg az összes adatot. A tesztelési eredményeket interpolált görbe formájában is megjeleníthetjük.

A „listener” elemek az alábbi kategóriákba sorolhatók:

  1. „Visualization listeners” (Megjelenítő Figyelő)

  2. „Data listeners” (Adat Figyelő)

  3. Egyéb

Megjelenítő figyelők

A „Graph Full Results”, „Graph Results” és a „Spline Visualizer” mindegyike grafikusan, valós időben ábrázolja a teszt eredményeket. A „Graph Results” (a 20-6. ábrán látható) ezek közül a legegyszerűbb és legnépszerűbb, mely kékkel ábrázolja az átlagos válasz időt, pirossal a szórást, lilával a mediánt, zölddel az áteresztőképességet és feketével az egyedi adat pontokat. Grafikon nézetben a medián és az áteresztőképesség rejtve vannak. Az ábrán a felső vonal a szórás, az alsó vonal az átlagos válaszidő, az adat pontokat pedig pontokkal ábrázoltuk.

20-6. ábra: Egy példa „Graph Results listener” elem.

Adat alapú figyelők

Ebbe a kategóriába tartoznak a „Simple Data Writer”, a „View Results in Table” és a „View Results Tree” „listener” típusok, melyek a szerver által visszaadott nyers adattal, válasz idővel és kóddal dolgoznak. A „Simple Data Writer” típus egy kissé feleslegesnek tűnhet, mivel minden más „listener” elemmel is fájlba menthetőek a nyers adatok. De abban az esetben, ha nem használunk másik „listener”-t, a „Simple Data Writer” hasznos lehet az adatok kimentésénél. A nyers adatok exportálása fontos lehetőség, hiszen így a felhasználónak lehetősége van más eszközökbe importálni és részletesebben elemezni azokat.

Az adatok fájlba írhatóak a „Write All Data to a File” lehetőségnél a fájl kiválasztásával (lásd 20-6. ábra). Alapértelmezésben a fájlformátum CSV, de a konfigurálás gomb használatával XML formátum is beállítható.

Az „Aggregate Report”, egy másik fajta „Data listener”, több mint a nyers adatok megjelenítésére használható figyelő. URL-enként rendezi el a nyers adatokat, és az URL által tartalmazott összes adat pontról összegzést szolgáltat. Ez egy hasznos és tömör módja a teljesítmény nyomon követésének, a grafikus megjelenítés és a nyers adatok figyelése közti egyensúly megteremtésének.

20-7. ábra: „Aggregate Report” elem segítségével a teszt eredmények könnyen értelmezhetőek.

Assertion Results

A „Sampler” elemekhez hozzáadott „Assertion” elemek eredményének megtekintését segíti elő.

Logic Controller

A „Logic Controller” (Logikai Vezérlő) elsődleges feladata a végrehajtási folyamat vezérlése. További, futtatható teszt eset elemeket tartalmaz. Egy „thread group” elemhez hozzáadott „Logic Controller” a szülő csomópontból egy egyszerű, futtatható csomópontnak látszik. Egy „Logic Controller” csomóponthoz hozzáadott elemek az adott „Logic Controller” szabályainak megfelelően fognak lefutni.

A „thread group” elemhez hasonlóan a „Logic Controller” elemhez hozzáadott elemek, „listeners”, „timers”, stb. a „Logic Controller” lokálisan látható elemei lesznek. A „Logic Controller” elemek a JMeter-ben tulajdonképpen a programozási nyelvek while, for, és function utasításainak felelnek meg, ezek a következők:

  1. Interleave Controller

  2. Switch Controller

  3. Simple Controller

  4. Loop Controller

  5. If Controller

  6. While Controller

  7. ForEach Controller

  8. Include Controller

  9. Module Controller

  10. Once Only Controller

  11. Random Controller

  12. Random Order Controller

  13. Runtime Controller

  14. Throughput Controller

  15. Transaction Controller

  16. Recording Controller

Interleave Controller

Minden egyes alkalommal, amikor az „Interleave Controller” (Soros Vezérlő) szülő csomópontja lefut, a „controller” is lefuttat egyet az alárendelt elemek közül. Az alárendelt elemek lefuttatásának sorrendje megegyezik a konfigurációs fában lévő sorrendjükkel. Például, ha a felhasználó létrehozott egy „thread group”-t 14 ismétlés számmal, és alatta egy „Interleave Controller”-t négy alárendelt elemmel, akkor a „controller” elemhez tartozó valamennyi elem három alkalommal fut le, majd a sorrendben első két elem még egy negyedik alkalommal is lefut (4 + 4 + 4 + 2 = 14).

Az „Interleave Controller” elemmel jól tesztelhető az olyan folyamat, amikor minden egyes kérés az őt megelőző kérés sikeres befejezésétől függ. Például egy online vásárló alkalmazás esetében a felhasználó először megkeresi az árut, beleteszi a kosarába, megadja a kártyája adatait, majd véglegesíti a rendelést.

Switch Controller

A „Switch Controller” (Kapcsoló Vezérlő) minden iterációban egy alárendelt elemet futtat le, csak úgy, mint az „Interleave Controller”, azonban, ahelyett, hogy sorban futtatná le őket, egy változóban meghatározott érték szerinti sorrendet tekint.

Simple Controller

A „Simple Controller” (Egyszerű Vezérlő) minden alárendelt eleme lefut mindannyiszor, ahányszor a „thread group” lefut. A „Simple Controller” a teszt elemek logikai elrendezésére használható, mint ahogy a könyvtárak a fájlrendszerben logikailag elkülönítik a fájlokat. Ha egy sok funkcionalitással bíró oldalt vetünk alá terheléses tesztelésnek, hasznos lehet „Simple Controller”-t használni a tesztelt funkcionalitások és a kapcsolódó modulok elválasztására, hogy a teszt eset átlátható maradjon. Ez olyan, mint amikor nagy szoftver projektek esetében a projekt modulokra és funkciókra osztásával fokozzák a szoftver fenntarthatóságát.

Loop Controller

A „Loop Controller” (Ismétlés Vezérlő) a konfigurációs beállításainál megadott alkalommal futtatja le az összes alárendelt elemet. Tehát valamennyi „Loop Controller” alá rendelt elem annyiszor fog lefutni, amennyi a beállított érték, szorozva a szülő csomópontnál beállított ismétlés számmal. Ha egy „Logic Controller” ismétlés száma négyre van beállítva, és a szülő „thread group” ismétlés száma is négy, akkor a „Logic Controller” valamennyi alárendelt eleme 16 alkalommal fog lefutni.

If Controller

„If Controller” (Ha Vezérlő) segítségével az alárendelt elemek lefutása egy feltételtől tehető függővé.

While Controller

A „While Controller” (While Vezérlő) addig futtatja le újra és újra az alárendelt elemeket, amíg a megadott feltétel hamis.

Module Controller

„Module Controller” (Modul Vezérlő) segítségével a felhasználó teljesen más helyekről adhat hozzá a teszt esethez elemeket. Más szóval, a „Module Controller” segítségével módszereket futtathatunk (más szóval függvényt, eljárást). A „Module Controller” különösen hasznos, ha a tesztelésnél szeretnénk alkalmazni a programozók által kedvelt újrafelhasználási alapelveket. Ez a fajta „controller” jól használható akkor is, ha a teszt elemek fizikai mozgatása nélkül szeretnénk megtervezni egy teszt esetet. A „Module Controller” a 20-8. ábrán látható.

20-8. ábra: „Module Controller” konfigurálása.

Once Only Controller

Nem meglepő módon a „Once Only Controller” (Csak-Egyszer Vezérlő) alárendelt elemei a terheléses tesztelés során csak egyszer futnak le. Ez a fajta „controller” használható kezdeti bejelentkezés lefuttatására, olyan alkalmazás entitás létrehozására, melytől más tesztek függnek (például egy megrendelés elkészítése online vásárlás esetén, mely azután kéréseken keresztül manipulálható), vagy bármilyen más olyan művelet elvégzésére, melynek csak egyszer kell lefutnia.

Random Controller

A „Random Controller” (Véletlen Vezérlő) úgy működik, mint az „Interleave Controller”, egy kivétellel: amíg az „Interleave Controller” az alárendelt elemeket egymás után, sorrendben futtatja le, addig a „Random Controller” minden alkalommal véletlenül választ egy elemet az alárendelt elemei közül.

Throughput Controller

A „Throughput Controller” (Áteresztőképesség Vezérlő) egy olyan mechanizmust szolgáltat a teszteléshez, mellyel korlátozhatjuk az elküldött kérések számát. A „controller” a neki küldött kéréseknek csak egy részhalmazát küldi tovább az alárendelt elemeinek. Ez a részhalmaz definiálható teljes vagy százalékos módon. Például a „Throughput Controller” beállítható úgy, hogy a kért futtatásoknak csak az 50 százalékát küldje tovább, vagy úgy, hogy csak az első 10 kérést. A „Throughput Controller” úgy is konfigurálható, hogy a „Once Only Controller” működését utánozza.

A „Throughput controller” beállítható még úgy is, hogy a „thread group” elemben lévő összes szálat együttesen korlátozza, vagy úgy, hogy külön-külön. Ez a lehetőség a „Per User” jelölőnégyzettel választható. Ha tehát ezt a lehetőséget választjuk, a „controller” minden szálat egyenként korlátoz, ellenkező esetben a korlátozásokat az egész „thread group”-ra együttesen alkalmazza.

Recording Controller

A „Recording Controller” (Rögzítés Vezérlő) teljesen eltérő módon használható, mint az eddigi „controller” típusok. A „HTTP Proxy Server” eszközzel engedélyeztethető a web böngésző által küldött kérések rögzítése, majd azok felhasználása egy teszt eset részeként A „HTTP Proxy Server” a neki küldött adatok mentésére használja a „Recording Controller”-t.

Sampler

Ahogy azt az első példánk esetében már említettük, a „sampler” (Minta) elemek a szerverek számára elküldött kéréseket generálják. Az alábbiak a gyakrabban használt „sampler” típusok:

  1. FTP Request

  2. HTTP Request

  3. WebService Request (SOAP, XML-RPC)

  4. Java Request

  5. JDBC Request

  6. JMS Request (Point to Point, Publisher és Subscriber)

  7. JUnit Request

  8. LDAP Request

Látható, hogy a JMeter nem csak web szerverek terheléses tesztelésére használható. Változatos teszt esetek készíthetőek a fenti „sampler” típusok felhasználásával. Bár valamennyi típus nagyon érdekes, ez a fejezet a „HTTP Request sampler” elemmel foglalkozik részletesebben.

Config Element

„Config Element”-ek (Konfigurációs Beállítások) felhasználásával lehetőségünk nyílik „sampler” eleme egész sorára változatos konfigurációs beállításokat alkalmazni globálisan. A „HTTP Request” esetében négy különböző „Config Element” használható:

  1. „HTTP Header Manager” (HTTP Fej Menedzser)

  2. „HTTP Authorization Manager” (HTTP Hitelesítési Menedzser)

  3. „HTTP Cookie Manager” (HTTP Süti Menedzser)

  4. „HTTP Request Defaults” (HTTP Kérések Alapbeállításai)

Bár a „thread group” elemekhez vagy egyéb „sampler”-t tartalmazó elemekhez a „Config Element” elemek alapvetően hozzá vannak rendelve, a globális értékek felüldefiniálhatóak az egyes „sampler” elemekhez külön hozzáadott „Config Element” elemeken keresztül.

HTTP Header Manager

Néhány esetben, hogy valós képet kapjunk az alkalmazás teljesítményéről, speciális HTTP „header” beállítás szükséges. Például, ha az alkalmazás válasza függ a böngésző típusától, mely a kérést küldte, akkor szükség van a User-Agent mező beállítására a teszt kérések elkészítésekor. „HTTP Header Manager” használatával a „header”-ben lévő mezők értéke minden egyes kérés esetén explicit beállítható. A „HTTP Header Manager” elemet felvehetjük egy „HTTP Request” elem alárendeltjeként, ekkor csak ezen kérések esetében lesz elküldve az elkészített „header”. Ellenben, ha egy „thread group” elem alárendeltjeként vesszük fel, valamennyi, a „thread group” alá rendelt kérés esetén elküldésre kerül a beállított „header”.

A „HTTP Header Manager” konfigurálása egyszerű, és nagyon hasonlít a „HTTP Request” elem Name/Value paramétereinek beállításához.

HTTP Authorization Manager

A „HTTP Authorization Manager” olyan kéréseket kezel, melyek HTTP autentikációt igényelnek. A „HTTP Header Manager”-hez hasonlóan, közvetlenül hozzáadhatjuk egy „HTTP Request” elemhez vagy egy „thread group” elemhez. Konfigurálása egyszerű, meg kell adni az URL-t, ahonnan a hitelesítési információkat megpróbálják elküldeni, valamint a felhasználónevet és a jelszót.

HTTP Cookie Manager

Számos modern web alkalmazás használ sütiket valamilyen módon. Ebben az esetben a teszt esethez egy „HTTP Cookie Manager”-t kell hozzáadni. A „HTTP Cookie Manager” elemnek megadható a sütik listája, melyet minden kérés esetén elküld. Ilyen módon a „sampler” képes utánozni egy olyan böngészőt, mely korábban már meglátogatott egy web oldalt. Továbbá a „HTTP Cookie Manager” képes utánozni a böngészők azon tulajdonságát is, hogy megkapják, tárolják és újraküldik a sütiket. Ennek megfelelően, például, ha egy süti dinamikusan hozzá van rendelve minden egyes látogatóhoz, akkor a „HTTP Cookie Manager” megkapja, majd minden megfelelő későbbi kérés esetén újraküldi azt.

A jövőbeli hatás mértékétől függően, a „HTTP Cookie Manager” hozzáadható „thread group” elemhez és közvetlenül egy „HTTP Request” elemhez is.

Megjegyezzük, hogy a „HTTP Cookie Manager” a sütiket szál (felhasználó) alapján tárolja. Tekintsünk egy 10 szálból álló „thread group” elemet. Ha minden szál egyedi sütit kap ugyanazon URL-hez, minden szál a saját, egyedi sütijét fogja újraküldeni. Ellenben, ha a sütit manuálisan adjuk hozzá a „Cookie Manager” elemhez, minden szál azt az egy, közös sütit fogja újraküldeni. A JMeter későbbi verzióiban javításra fog kerülni ez a korlátozás.

HTTP Request Defaults

A „HTTP Request Defaults” elem kényelmes mechanizmust nyújt a gyakori paraméterek értékeinek megosztására egyedi „HTTP Request Sampler” elemek között. A kérések gyakori paraméterei (úgy mint protocol, host, port, path és name/value) egy helyen beállíthatóak, és megoszthatóak a „sampler” elemek között.

Assertions

Hiába válaszol egy alkalmazás villámgyorsan, ha a válasz, amit adott, érvénytelen. „Assertion” (Állítás) használatával módunk nyílik a kérések erdményének helyességét ellenőrizni. Ezáltal a felhasználók nem csak a szerver válaszképességében, de megbízhatóságában is biztosak lehetnek. „Assertion” elem „Sampler” alá rendelt elemként hozható létre (csak úgy, mint a „HTTP Request Sampler”). Egy „Assertion” állításokat tartalmaz, amelyeket meg kell vizsgálnunk.

Például létrehozhatunk egy „Assertion”-t, melyben rögzítjük, hogy a szervertől visszakapott válasznak tartalmaznia kell a Hello szót. Ezek után, ha azon „HTTP Request” elem válasza, melyhez hozzáadtuk az „Assertion”-t, nem tartalmazza a Hello szót, akkor „assertion failure” hibaüzenetet kapunk.

Az ábrán a „Hello World!” szöveg már hozzá van adva az „Assertion” elemhez. Ezt úgy tehetjük meg, hogy az „Add” gombra kattintva beírjuk a szöveget a megjelenő üres szövegmezőbe. Ha a „Contains” opció van kiválasztva, akkor a válasz tartalmában keresi (nem kell teljes azonosság), ha pedig a „Matches” opciót választjuk, akkor pedeg teljes azonosság a sikeresség feltétele.

20-9. ábra: A „Response Assertion” elem konfigurációs képernyője.

Miután elkészítettünk egy „Assertion” elemet, szükségünk van még egy „Assertion Results listener” elemre a sikeres és sikertelen válaszok megjelenítéséhez. Az „Assertion Results listener” elemet a „HTTP Request Sampler” elem szülő „thread group” csomópontjához kell hozzáadni. Az „Assertion Results listener” elem semmilyen konfigurációt nem igényel. Az adott „thread group” elemhez tartozó minden „Assertion” elem minden eredményét megjeleníti. Ha az ellenőrzés sikeres, a kérés forrását (ebben az esetben az URL-t) azonosító szöveget jelenít meg. Ellenkező esetben hibaüzenet jelenik meg a forrás azonosítója alatt, melyben a hibás minta is megtalálható.

Összefoglalva tehát a „Response Assertion” elem használható arra, hogy megvizsgáljunk egy válasz URL-t vagy törzset, hogy tartalmaz-e egy előre megadott mintát. Léteznek egyéb „Assertion” típusok is:

  1. „Duration Assertion” (Időtartam Állítás): Ellenőrzi, hogy a válasz egy megadott időtartamon belül érkezzen meg.

  2. „Size Assertion” (Méret Állítás): A válasz méretét ellenőrzi bájtban, és összehasonlítja egy megadott értékkel (= | < | > | <= | >=).

  3. „XML Assertion” (XML Állítás): Biztosítja, hogy a válasz egy helyesen formázott XML legyen. Nem ellenőrzi, hogy a „Document Type Definition” (DTD) vagy egyéb séma típusok érvényességének is megfelel-e.

Ezen „Assertion” elemek a „Response Assertion” elemhez hasonló módon konfigurálhatóak és adhatóak hozzá egy teszt esethez.

http proxy server

„HTTP Request” elemek készítése egy idő után fárasztóvá válhat. A JMeter által nyújtott „HTTP Proxy Server” eszköz segítségével nyomon követhetjük egy böngésző tevékenységét, és a böngésző kérései alapján „HTTP Request” elemeket generáltathatunk automatikusan. Ahogy a 20-10. ábrán látható, a proxy elfog minden kérést, amit a böngésző küld, azokat JMeter „HTTP Request” elemmé alakítja, majd továbbküldi a kéréseket a cél szerver felé.

Először hozzá kell adnunk a „HTTP Proxy Server” elemet a „WorkBench” elemhez. Jobb egérgombbal kattintsunk a „WorkBench” ikonján, és válasszuk az „Add”, majd a „Non-Test Elements”, végül pedig a „HTTP Proxy Server” menüpontokat. A proxy konfigurációs képernyője a 20-11. ábrán látható. Megjegyezzük, hogy a „WorkBench” elem alatt egy „Recording Controller” is definiálva van, mely „Target Controller” elemként van beállítva a „HTTP Proxy Server”-nél. Mikor kérések futnak át a proxy szerveren, ezen „Recording Controller” elem alatt válnak láthatóvá a rekordok.

Megjegyezzük, hogy a port számot (alapértelmezésben 8080) 9090-re változtattuk.

Ha a Tomcat és a JMeter ugyanazon a gépen futnak, és az alapértelmezés szerinti 8080-as portot használják, akkor ütközni fognak. Ilyen gépeken a JMeter proxy szerverének port számát át kell állítani, egy a rendszer által nem használt port számra.

20-10. ábra: A JMeter Proxy Szerver a böngésző és a web oldal között helyezkedik el.

20-11. ábra: A „HTTP Proxy Server” elem konfigurációs képernyője.

A „Patterns to Include” és a „Patterns to Exclude” szövegmezőkben reguláris kifejezések adhatóak meg, amelyek illeszkednek az URL-ekre, melyek számára a „HTTP Request” elemeket generáltatjuk. Bár a böngésző teljes forgalma áthalad a „HTTP Proxy” elemen, csak azon kérések lesznek „HTTP Request” elemmé alakítva, melyek illeszkednek valamelyik „include” mintára, és nem illeszkednek az „exclude” mintákra.

Ha beállítottuk a proxy szervert, a „Start” gombra kattintva indíthatjuk el. Mivel a JMeter-t állítottuk be proxy szerverként, minden web szervernek küldött kérés a JMeter proxy szerverén halad keresztül. Ezeket a kéréseket a JMeter elfogja, „HTTP Request” elemmé alakítja őket, és a „WorkBench” elem alá felvett „Recording Controller” elem alá helyezi el. Ezek az elemek utána egyszerűen áthúzhatóak a teszt eset alá.

8.1.4. Elosztott terheléses tesztelés

A JMeter rendelkezik azzal a tulajdonsággal, hogy a hálózaton elosztott JMeter példányokat képes koordinálni, utasítani őket ugyanazon terheléses teszt elvégzésére. Ezen funkció eléréséhez, egy vagy több JMeter példányt server módban kell elindítani. Egy JMeter kliens (ez a szabványos JMeter GUI interfész) képes kapcsolódni egy szerver módban futó JMeter példányhoz, és irányítani azt. A JMeter kliens „listener” eszköze kapja meg a szerver módban futó JMeter példányok által generált adatokat. Ennek a tulajdonságnak két lehetséges felhasználási területe van:

  1. „Scalability” (Skálázhatóság): Több okból kifolyólag előfordulhat, hogy egyetlen JMeter példány nem képes a web alkalmazást a végletekig elárasztani kérésekkel. Ezekben a ritka esetekben a JMeter elosztott tulajdonságát használhatjuk fel, hogy igazán nagy terhelésnek vessük alá a web alkalmazást. Ez a tulajdonság használható még az úgy nevezett „distributed denial of service” (DDoS) támadás koordinálására, amely jól kihangsúlyozza: Ne vess alá terheléses tesztelésnek olyan web oldalt, melyet nem tartasz az irányításod alatt!

  2. „Server Proximity” (Szerver távolság): Képzeljük el, hogy Budapesten ülve szeretnénk terheléses tesztet futtatni egy Japán szerveren. Nehéz bármilyen mértékben elfogadni ezen teszt eredményét, mivel a hálózat és a csomagvesztés kritikus szerepet játszhatnak a folyamatban – hacsak először nem pont ennek a tesztelése a célunk. Ebben az esetben lehetséges, hogy a tesztelni kívánt szerverhez fizikailag közel fekvő szerverre telepítsük a JMeter szervert, és azután ezt a szervert használjuk a teszt távoli elvégzéséhez.

A 20-12. ábrán megfigyelhetjük, ahogy egy JMeter kliens több JMeter szervert irányít.

20-12. ábra: Egy JMeter kliens több JMeter szervert képes irányítani.

A következőkben lépésről lépésre bemutatjuk, hogyan állíthatjuk be és futtathatunk teszteket a JMeter szervert használva:

  1. Telepítsük a standard JMeter disztribúciót a megfelelő JMeter szerver gépen.

  2. Minden irányítani kívánt JMeter példány esetében indítsuk el a szerver folyamatot a JMeter bin könyvtárában található jmeter-server.bat vagy jmeter-server shell szkript futtatásával (operációs rendszertől függően). Windows alatt néha megjelenik a „Windows cannot find rmiregistry.” hibaüzenet. Ebben az esetben a PATH környezeti változóhoz adjuk hozzá: %JAVA_HOME%/bin.

  3. A kliens gépen szerkesztésre nyissuk meg a JMeter bin könyvtárában található jmeter.properties fájlt.

  4. A remote_hosts tulajdonságot vegyük ki megjegyzésből és változtassuk meg úgy, hogy vesszővel elválasztva legyenek felsorolva a JMeter szerver gépek. Ez lehet egy feloldható DNS név vagy IP szám.

  5. Indítsuk el a JMeter klienst a jmeter.bat vagy jmeter shell szkript futtatásával.

  6. Nyissunk meg egy teszt esetet, vagy készítsünk egy újat.

  7. A „Run” menüben két új lehetőség jelenik meg: „Remote Start” és „Remote Stop”. Ezekkel a lehetőségekkel a remote_hosts tulajdonságnál felsorolt szerverek mindegyike leállítható vagy elindítható.

  8. Ezek után ugyanúgy használhatjuk a JMeter felhasználói felületét, mint korábban.

8.1.5. Teszt eredmények értelmezése

Sok adatot generálni egy dolog, értelmezni azokat egy másik. Az eredmények elemzésének két alapvető módja van:

  1. Teljesítmény célok kitűzése és azok tesztelése

  2. A skálázhatóság korlátainak megállapítása

Célok kitűzése és tesztelése

Web alkalmazás készítésének egy különösen hatékony módja, ha először a teljesítmény célokat tűzzük ki. Ezek a célok tartalmazhatják a következő metrikák valamelyikét:

  1. Mennyi az átlagos várakozási idő, amíg egy kérés teljesül?

  2. Mennyi a leghosszabb várakozási idő?

  3. Mennyi konkurens kérés után következik be hiba?

Ha már egyszer sikerült hasonló célokat megfogalmaznunk, könnyen megállapíthatjuk, hogy a tesztelt web alkalmazás megfelel-e ezeknek. Mind az „Aggregate Report”, mind a „Graph Results listener” kiválóan megfelel erre a célra.

Tételezzük fel a következő szituációt: egy egyszerű web oldalnak öt konkurens felhasználót kell tudnia kezelni, ahol a konkurens azt jelenti, hogy a felhasználók nem több, mint egy másodpercenként küldenek egy kérést. Minden felhasználó átlag 250 ezred másodpercen belül kapjon választ, és 3 másodperc maximális várakozási idő még elfogadható.

A szituáció folytatásaként tételezzük fel, hogy terheléses tesztelést végeztünk az alkalmazáson a fenti célokban megfogalmazott kritériumokra nézve. A 20-13. ábra mutatja a teszt esetből készített „Aggregate Report” képernyőjét.

20-13. ábra: A példa szituációnk „Aggregate Report” képernyője.

Az „Aggregate Report” képernyőjéről tisztán látható, hogy a web alkalmazásnak nem sikerült a kitűzött célokat teljesítenie. Az átlagos válasz idő 876 ezred másodperc (ms), ami nagyjából háromszor rosszabb a kitűzöttnél. A maximális várakozási idő 4984 ezred másodperc, majdnem öt másodperc. Pozitívumként megemlíthető, hogy egy kérés sem végződött hibával.

Ahogy a 20-14. ábrán látható, a „Graph Results listener” használatával további értékes információkhoz juthatunk.

Megjegyezzük, hogy az ábrán csak a „Data” grafikon van engedélyezve. Így könnyebb fekete-fehérben értelmezni a grafikont. A pontok jelölik az egyes minták válaszidejét ezred másodpercben. A magasabb pont hosszabb válasz időt jelent. Így a grafikon finomabb részletességgel mutatja az alkalmazás teljesítményét, amely jól láthatóan egyáltalán nem következetes.

Egy külön statisztika, a „deviation” (szórás) támasztja alá ezt a megfigyelésünket. A szórás (általában „standard deviation” (normális szórás)) azt méri, hogy a mintában lévő értékek milyen mértékben térnek el az átlag értéktől. A nagyobb szórás nagyobb eltéréseket jelent a válaszidőben.

A grafikon egy másik új statisztikát, „median” (medián) is nyújt. Ha a válaszidőket nagyság szerint sorrendbe állítjuk, a medián a középső elem lesz.

20-14. ábra: Példa szituációnk „Graph Results” képernyője.

A grafikonon látható „throughput number” érték megegyezik az „Aggregate Report” „rate” értékével.

A skálázhatóság korlátainak megállapítása

Néha a teljesítmény célok nem érdekesek, és az egyetlen motiváló tényező, meghatározni azt a pontot, ahol a web alkalmazás összeomlik.

Ilyenkor jön jól a JMeter, különösen az elosztott tesztelő tulajdonsága. Fontos megjegyeznünk, hogy a stressz tesztet úgy kell elkészítenünk, hogy a való világ szituációit reprezentálja. Nem túl hasznos például egy olyan információ, hogy ha 10,000 felhasználó minden 10 ezred másodpercben konkurens kéréseket küld, akkor a web alkalmazás meghibásodik, mivel ilyen szituáció nem túl gyakran fog előfordulni a való világban. Sokkal hasznosabb tudnunk például, hogy ha 500 felhasználó egyidejűleg küld kéréseket (minden kérés között 3 másodperc szünettel), akkor a web alkalmazás a válaszok 4 százalékában hibát dob.

Stressz teszt esetén az „Aggregate Report” nagyon jól használható a hibák arányának ábrázolásához, és beállítható, hogy további elemzés céljából minden jelentkező hibát naplózzon.

További elemzés

A JMeter természetesen képes a teljesítmény adatokat elmenteni, hogy más alkalmazásokban elemezhessük azokat. Habár jelenleg nincs (jól ismert) speciálisan a JMeter-hez tervezett teljesítmény elemző eszköz a köztudatban, a népszerű programok, úgy mint Microsoft Excel, képesek importálni a JMeter adatait, és mindenféle hasznos jelentést és grafikont készíteni belőlük. Alapértelmezésben a JMeter mind XML, mind „Comma Separated Value” (CSV) formátumban el tudja menteni az adatokat. Ez a jmeter.properties fájlban a jmeter.save.saveservice.output_format tulajdonság xml vagy csv értékre változtatásával állítható be. A jmeter.properties fájl a JMeter telepítési könyvtárában a bin alkönyvtárban található.

8.1.6. Mi a teendő a teljesítmény tesztelése után

A kezdeti teljesítmény tesztek elvégzése után, ha web alkalmazásunkat nagyon lassúnak találtuk, vagy az nem képes megbirkózni a felhasználók tömegével, kísértést érezhetünk, hogy megoldjuk a problémát, a lassúnak tűnő részek újbóli elkészítésével, vagy több hardver hozzáadásával, és így tovább. Ne tegyük!

Fontos, hogy beazonosítsuk az okát, amiért az alkalmazás ilyen lassú, és hogy megtaláljuk a szűk keresztmetszetet. Ez egy összetett feladat, amely közreműködést igényel mind a rendszer adminisztrátor, mind a web alkalmazás fejlesztőjének részéről.

Néhány jó tanács, melynek segítségével beazonosíthatjuk a teljesítmény probléma forrását:

  1. Figyeljük a rendszer információkat, úgy mint a szerver CPU és memória felhasználását. Linux alatt a „top”, „iostat” és „vmstat” eszközök, Windows alatt a „Task Manager” és a „PerfMon” lehetnek segítségünkre.

  2. Az adatbázishoz kapcsolódó feladatok gyakran alkotják a teljesítmény szűk keresztmetszetét. Használjuk az adatbázisunk gyártója által nyújtott diagnosztikai eszközöket. A „P6Spy” (www.p6spy.com) egy nyílt forráskódú eszköz erre a célra.

  3. Hangoljuk a gyenge teljesítmény területek megtalálására a web alkalmazásunk kódját, ami azt jelenti, hogy olyan kóddal bővítjük ki alkalmazásunkat, mely figyeli és rögzíti bizonyos feladatok elvégzéséhez szükséges időmennyiséget. Ez tipikusan olyan utasítások formájában történhet, melyek a műveletek elvégzéséhez szükséges időt naplózzák. A 19. fejezetben láthattuk, hogy hogyan adhatunk hozzá naplózó utasításokat web alkalmazásunkhoz.

  4. Használjunk profil készítő eszközöket web alkalmazásunk elemzésére, a terhelés alatt megmutatkozó viselkedés grafikus megjelenítésének elkészítésére, és az egyes modulok hívási grafikonjának ábrázolására. A hívási grafikon egy olyan diagram, amely megmutatja, hogy melyik rendszer modul melyik másik modult hívja. Néhány népszerű web alkalmazás profilt készítő eszköz, beleértve a kereskedelmieket is, a „JProbe” (www.quest.com/jprobe/), az „OptimizeIt” (www.borland.com/optimizeit/) és az „Eclipse” ingyenes „Test and Performance Tools Platform” (www.eclipse.org/tptp/) eszköze.

Ezen eszközök használatának célja, hogy meghatározzuk vele az alkalmazásunk teljesítményének szűk keresztmetszetét. Ha egyszer megértettük, mik alkotják a szűk keresztmetszetet, elkezdhetünk speciálisan foglalkozni azokkal.

8.1.7. Összefoglalás

A teljesítmény tesztelés egy fontos, de gyakran elhanyagolt tevékenység. Amellett, hogy skálázhatóvá tehetjük az alkalmazásunkat, segíthet döntést hozni a rendszer felépítését illetően, és megerősítést nyerhetünk korábbi döntéseinkkel kapcsolatban. Ebben a fejezetben a következő témaköröket tekintettük át:

  1. Mindenekelőtt el kell döntenünk, mit is akarunk mérni, és létre kell hoznunk egy teszt esetet. A teszt esetet a kívánt teljesítménynek megfelelően (mennyi konkurens felhasználó támogatott, elvárt válaszidő, elvárt áteresztőképesség) készítsük el.

  2. A teszt esetnek tartalmaznia kell a szimulálni kívánt felhasználói tranzakciókat, a terhelést, melynek alávetjük az alkalmazást, és a tesztelés környezetét.

  3. A skálázhatóság (a rendszer azon képessége, mellyel a megnövekedett terhelést kezeli teljesítmény és megbízhatóság csökkenés nélkül) több tényezőtől függ. Tomcat rendszer esetében ilyen tényező a szerver hardver, a szoftver konfiguráció és a telepítés architektúrája.

  4. A JMeter a Jakarta projekt teljes funkcionalitású, nyílt forráskódú tesztelője. Különböző JMeter terheléses teszteléshez használható technika került bemutatásra.

  5. A teljesítmény tesztelésének befejezése után, a teszt eredmények segítenek felfedni a gyenge teljesítmény okát. Ezt még az előtt kell megtennünk, mielőtt bármilyen változtatást hajtanánk végre a teljesítmény növelésének céljából.