JMeter - A performancia tesztelés hasznos fogásai

Az előző cikkem folytatásaként a múltkor ismertetett JMeter-es tesztesetet fogom véglegesíteni, továbbá bemutatok pár hasznos gyakorlati fogást is.

 
Időzítők hozzáadása

A Recording Controller alá felvett HTTP kéréseket a JMeter szálak (mint felhasználók) szünet nélkül hajtják végre, így érdemes időzítőket (Timers) is felvenni a felhasználók gondolkodási idejének reprezentálásához. Az időzítők mindig egy adott hatókörhöz tartoznak, több időzítő felhasználása esetén a késleltetések összeadódnak. Többféle időzítő közül is választhatunk, azonban én a Gaussian Random Timer-t szoktam használni, ahol is megadhatunk egy konstans késleltetést és egy ehhez képesti eltérést a Gauss görbe szerint.

Itt felmerül az a kérdés, hogy milyen várakozási időket állítsunk be az időzítőkhöz? Mivel a célunk a felhasználók gondolkodási idejének pontos modellezése, a válasz egyszerű! Az éles rendszeren figyeljük meg, hogy a felhasználók mennyi időt töltenek az egyes oldalakon és ezen megfigyelések alapján állítsuk be az értékeket!

CSV alapú adatforrás kialakítása

Adatforrásokat akkor érdemes felhasználni, amikor pl. a szerver elérhetőségét nem akarjuk beégetni a tesztesetbe vagy ha bizonyos kéréseket mondjuk felhasználónként eltérő paraméterekkel akarunk futtatni. A felhasználók belépése pont egy ilyen esemény, ahol is a "valódi" felhasználókhoz hasonlóan mindig egy újabb felhasználónév/jelszó párossal kellene elvégezni a bejelentkeztetést. Ehhez a CSV Data Set Config konfigurációs elemet használhatjuk fel az alábbi ábra alapján.

A filename mezőben adjuk meg a csv fájl elérhetőségét, ami esetünkben a felhasználónév jelszó párosokat fogja tartalmazni. Tehát az adatokat a csv fájl sorai fogják tartalmazni, amelyekre az ${USERNAME} ill. ${PASSWORD} kifejezésekkel hivatkozhatunk a http kéréseknél mint ahogy az alábbi ábra is mutatja. Így egyszerűen megoldódott az egyedi felhasználók beléptetése a teszteléshez.

Végül megjegyezném, hogy a csv adatok felolvasása "körbeforgó" működés szerint zajlik, azaz ha elfogytak az adatok a felolvasás elölről kezdődik.

Ellenőrzési feltételek megadása

Az ellenőrzési feltételek (Assertions) lehetőséget adnak arra, hogy a HTTP kérésekre kapott válaszok helyességét leellenőrizzük. Ilyen feltétel lehet például a HTTP 200-as státuszkód ellenőrzése vagy valamilyen szövegrészlet tartalmazásának vizsgálata a válaszban (pl.: ne legyen a 'hiba' szó az oldalon). A Size Assertion segítségével könnyen ki tudjuk szűrni, ha mondjuk nagy terhelésre üres oldalt vagy rövid hibaüzeneteket kapnánk vissza. A hatókörök ilyenkor is szerepet játszanak, mert amíg egy Recording Controller alá felvett assertionok minden kérésre kiértékelődnek, addig a HTTP kérésekhez felvett assertion-ök más elemre nem lesznek érvényesek. Az alábbi ábra egy response assertion-t mutat a 404-es hibára vonatkozólag.

Mérési eredmények rögzítése és megtekintése

Az erdmények rögzítéséhez a Recording Controller alá vegyünk fel néhány Listenert. Az Aggregate Report-ból (jobb klikk a Recording Controlleren/Listeners/Aggregate Report) vagy a Summary Report-ból kiolvashatók a fontosabb jellemzők, ahogy az alábbi ábra is mutatja. A mérési eredmények az egyes oldalakra vonatkozólag külön-külön is megjelennek, így ha valamelyik oldalnál magas értékeket kapnánk ott kellene kicsit körülnézni optimalizálási célokból!

Itt jegyezném meg, hogy a belassulás okának kiderítése nem mindig egyszerű feladat, főleg amikor a kérések több rendszeren is keresztül haladnak pl. nagyvállalati és banki alkalmazásoknál! Ilyenkor általában a napló állományokból szokás kinyerni az információkat, de van erre egy egyszerűbb megoldás is amiről hamarosan írni is fogok! Ha a téma felkeltette az érdeklődésed, nézz vissza később is a blogomra! .)

A Graph Results listener panelon a Summary Report néhány értékét láthatjuk kirajzolva egy diagramon, ami kifejezetten előnyös ha az értékek változását folyamatosan is szeretnénk követni.

A View Results Tree pedig lehetőséget ad a HTTP kérések és a kapott HTTP válaszok megtekintésére, ami  hasznos tud lenni a teszt közbeni hibakereséskor vagy ha éppen arra lennénk kíváncsiak, hogy a csv adatforrásból milyen értékek kerültek behelyettesítésre.

A JMeter teszt indítása

Utolsó simításként a hírek, a termékek és a dokumentumok megtekintéséhez felvettem egy-egy ciklust ahol is egy elem lekérésére kerül sor. A ciklusra 3-as lefutási számot állítottam be, majd a ciklusok alá hozzáadtam egy-egy adatforrást amiben a lekérendő elemek azonosítói találhatók meg. Ezeket az adatforrásokat mindenféleképpen a ciklusok alá kell felvenni, egyébként ha a Recording Controller alá tettem volna be, akkor a ciklusok lefutásakor nem olvasódnának fel újabb értékek. (scoping)

Végül is betettem minden szükséges elemet így elérkezett a teszt szkript indítása, amit a run menüpont start menüelemére való kattintással hajthatunk végre. A teszteset indítása után a jobb fenti ikon zöldre vált és látható amint a felhasználók száma eléri a Thread Group-nál megadott maximumot.

Bár a teszt szkript elkészült, a következő bejegyzésem még biztos tartogat neked egy-két hasznos információt!