2012. február 22., szerda

JMeter - Terheléses tesztelés a gyakorlatban

Az előző bejegyzésemben véglegesítettem a JMeter-es teszt szkriptet, ebben a részben pedig kitérek a metrikákra majd összefoglalom a terheléses teszteléssel kapcsolatos tapasztalataimat. Kezdjük a mérendő jellemzők értelmezésével, melyeket az előző részben ismertetett Aggregate Report ill. a Summary Report segítségével kaphatunk meg.

Áteresztő képesség (Throughput)
Az áteresztőképesség megmutatja, hogy adott időegység alatt hány kérésre képes válaszolni a szerver. Az áteresztőképesség segítségével a szerver terhelhetőségét vizsgálhatjuk és akkor tekinthetjük megfelelőnek, ha hosszabb idő után (órák, napok) is konstans marad az értéke. 

Átlagos válaszidő (Average, Mean)
Az átlagos válaszidő, ami a kérés elküldésétől a válasz megérkezéséig eltelt idők átlagát adja. Az átlagos válaszidő időnként félrevezető is lehet, így az átlagot mindig a szórás és a min/max válaszidők tekintetében elemezzük. 

Szórás (Standard Deviation)
Az átlagtól való szórás mértéke megadja, hogy az értékek milyen messze estek az átlagtól, így ezzel a metrikával következtethetünk az átlag pontosságára. A kisebb szórás pontosabb átlagot mutat. Általános szabályként elmondható, hogy a szórás akkor tekinthető relevánsnak, ha az átlag felénél nem nagyobb az értéke.

Felező érték (Median, 50% Line)
A minták fele ez alá az érték alá esik. Az értéke akkor tekinthető mérvadónak, ha az adatok normál vagy egyenletes eloszlásúak. 

90% Line 
A minták 90%-a ez alá az érték alá esik. A mediánhoz hasonlóan az értéke akkor tekinthető mérvadónak, ha az adatok egyenletes vagy normál eloszlásúak.

Min, Max 
A minimális és a maximális válaszidőnek az értékét mutatja.


    Terheléses tesztelés a gyakorlatban

    A tesztek futtatása előtt először is fogalmazzuk meg, hogy mire vagyunk kíváncsiak! A példa kedvéért most vizsgáljuk meg, hogy hány felhasználóig terhelhető a rendszer ha minden oldal esetében 3.5 másodperc átlagos válaszidő alatt kívánunk maradni.

    A kérdés megválaszolásához a Summary Report eredményeit használhatjuk fel. Az első fázisban 1 órás időtartamokban futtassuk le a tesztet, úgy hogy a felhasználószámot óránként folyamatosan növeljük, majd egy excel táblázatba gyűjtsük ki az adott felhasználószámhoz tartozó eredményeket, amiből később grafikont is készíthetünk! Amikor valamelyik 1 órás teszt végén az oldalakhoz tartozó átlagos válaszidő meghaladja a 3.5 másodpercet, abbahagyhatjuk a tesztelést. Ha az eredménnyel nem vagyunk megelégedve a második fázisban jöhet a tunning, ahol is kiválasztjuk azt a felhasználószámot ahol a rendszer még éppen teljesítette a 3.5 sec kritériumot, majd egyszerre mindig csak egy tunning paramétert állítva - legyen ez JVM beállítás, Pool beállítás stb. - nézzük meg milyen irányban változik az eredmény, ha javulás látható tartsuk meg a beállított értéket és így haladjunk tovább.

    Tanácsok a JMeter 2.5 tesztek készítéséhez és futtatásához

    Bár a JMeter egy nagyon hasznos eszköz, pár apróságra azért érdemes odafigyelni!
    • Ha a Thread Pool beállításoknál megadjuk a "Loop Count" értékét, akkor a teszt vége fele a szálak fogyásakor néha lefagy a JMeter, érdemes inkább "Forever"-re állítani és mondjuk 1-2 óra után leállítani a tesztet.
    • Ha 20-30 percnél tovább kívánjuk futtatni a tesztjeinket akkor a Summary Report Listeneren kívül mást ne használjunk, mert néhány Listener esetén hamar elfogy a memória. A legjobb ha hosszú futtatás esetén konzolról indítjuk a tesztet az alábbi paranccsal: jmeter -n -t test.jmx -l test.jtl
    • A JMeter-es tesztek futtatása alatt monitorozzuk a szervert is (CPU, RAM, HDD), így beazonosíthatjuk a szűk erőforrásokat. Használhatjuk a JConsole-t vagy a VisualVM-et.
    • A HTTP Proxy Server "Patterns to exclude" beállításánál mindig szűrjük a cache-elt elemeket, mivel nem az "első látogatók"-hoz tartozó idők mérése a célunk.
    • Figyeljük meg, hogy a felhasználók átlagosan mennyi időt töltenek várakozással az éles rendszer oldalain és az időzítőket ezek alapján állítsuk be.
    • A teszteket ne arról a gépről indítsuk ahol a szerver is van, így a helyi futtatás nem fogja az eredményeket torzítani.
    • Ha van rá lehetőségünk a teszteket több órán át vagy napokig is futtassuk, így pontosabb eredményeket kapunk.
    • A tesztesetek bejelentkezéssel kezdődjenek és kijelentkezéssel záruljanak.
    • Az Aggregate Report ill Summary Report valamely mezőjébe belekattintva több tizedes jegy pontossággal is megtekinthetjük az értékeket.
    • Ha a rögzített http kérésekhez tartozó nevek nem beszédesek, a teszt felvétele közben egyből módosítsuk is ezeket.
    • A JMeter tesztek futtatása előtt az adatbázis tábláit mindig töltsük fel néhány száz rekorddal vagy akár annyival is amennyivel majd 4-5 év múlva számolunk, mivel a hibák egy része és a belassulások is legtöbbször csak nagyszámú rekord esetén jelentkeznek!

    A cikksorozat a közeljövőben még folytatódni fog, ahol is JSF és JBoss Seam alapú alkalmazások JMeter-es tesztelésének részleteiről fogok blogolni! Addig is várom az észrevételeket és hozzászólásokat!

    4 megjegyzés:

    1. Hasznos cikksorozat volt, köszönet érte!

      VálaszTörlés
    2. Szívesen! Örülök, hogy hasznosnak találtad és köszi a kommentet!

      VálaszTörlés
    3. Én is köszönöm a cikket, a Weblaborról jöttem ide. Igazán hasznos volt és tanulságos.

      VálaszTörlés
      Válaszok
      1. Szia!

        Köszi a kommentet. A JMeter egy kiváló eszköz a terheléses teszteléshez, azonban hatékonyabban dolgozhatunk vele ha integráljuk a dynaTrace-el. Erről hamarosan blogolni is fogok!

        Törlés