Mind az üzleti elemző mind a IT rendszerszervező munkája során eljön az alkalmazás tesztelés tevékenység melyben nagy segítség a tesztelés támogató alkalmazások csoportja.
Számos terheléses tesztet végző alkalmazás érhető el, beleértve a nyílt forráskódú szoftvereket és kereskedelmi csomagokat.
Ezen választékhalmazból a terheléses tesztelés egyik megoldásaként, az Apache projekt JMeter nevű alkalmazását mutatom 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 komponenssel is 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.
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.
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 szabadon 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 fogom 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.
Most még tartsuk meg az alapbeállításokat.
„Thread Group” hozzáadása során 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 5-re állítjuk (minden kérés ötször kerül elküldésre), akkor összesen 1000 kérést fog leküldeni az eszköz, amiből 200-200 közel egy idő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.
„HTTP Request” elem hozzáadása során a következő konfigurálási beállítások érhetőek el:
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.
A beállító 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 az alkalmazás szerer 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) legyen, az útvonal pedig az /examples/servlets/servlet/HelloWorldExample értékre legyen beállítva.
Ez az minta elérési útvonala az alkalmazás szerver á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 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.
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.
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.
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.
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.
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.
„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.
1. „Visualization listeners” (Megjelenítő Figyelő)
2. „Data listeners” (Adat Figyelő)
3. Egyéb
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” 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.
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.
A „Sampler” elemekhez hozzáadott „Assertion” elemek eredményének megtekintését segíti elő.
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
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.
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.
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” (Ha Vezérlő) segítségével az alárendelt elemek lefutása egy feltételtől tehető függővé.
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” (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 „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.
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.
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.
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”-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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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
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ó.
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.
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ó.
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.
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.
JMeter
Egy web alkalmazás terheléses teszteléséhez speciális szoftverek állnak rendelkezésre, amelyekkel normál teszt is végezhető.Számos terheléses tesztet végző alkalmazás érhető el, beleértve a nyílt forráskódú szoftvereket és kereskedelmi csomagokat.
Ezen választékhalmazból a terheléses tesztelés egyik megoldásaként, az Apache projekt JMeter nevű alkalmazását mutatom 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 komponenssel is 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.
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). 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ént2. 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.
Teszt eset fogalma, készítése és értelmezése JMeter segítségével:
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 szabadon 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 fogom 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.
Most még tartsuk meg az alapbeállításokat.
„Thread Group” hozzáadása során 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 5-re állítjuk (minden kérés ötször kerül elküldésre), akkor összesen 1000 kérést fog leküldeni az eszköz, amiből 200-200 közel egy idő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.
„HTTP Request” elem hozzáadása során a következő konfigurálási beállítások érhetőek el:
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.
A beállító 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 az alkalmazás szerer 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) legyen, az útvonal pedig az /examples/servlets/servlet/HelloWorldExample értékre legyen beállítva.
Ez az minta elérési útvonala az alkalmazás szerver á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 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.
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.
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.
Típusok:
„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” 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.
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.
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.
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.
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.
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.
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.
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.
Teszt eredmények értelmezése
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 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ó.
Mi a teendő a teljesítmény tesztelése után
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.
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.
Megjegyzések
Megjegyzés küldése