Webalkalmazások teljesítménytesztje

Háttér

Nagy terhelés alatt hajlamosabbak a hibák előjönni, ezért is szoktak összeomlani az előre beharangozott rendszerek az élesítéskor. Emiatt viszont fejlesztés közben is érdemes időnként egy kicsit megküldeni az alkalmazást, hogy lássuk, milyen teljesítményre képes, valamint egyes esetekben kiderülhetnek a szűk keresztmetszetek is.

Webalkalmazásoknál a sebesség csak másodlagos fontosságú. Míg desktopon a 0.2 másodpercnél további választ tekinthetjük lassúnak, a web sokkal lomhább, emiatt a felhasználók is türelmesebbek. Még ha nagyon gyorsan állítjuk is elő az oldalt, a hálózati késleltetés, utána pedig a rendering bőven efölé viszi a tapasztalt válaszidőket. Persze a végtelenségig nem lehet a felhasználót várakoztatni, de néhány másodperc még belefér. Sokkal fontosabb viszont az áteresztőképesség, tehát sok párhuzamos lekérés esetén hányat tud kiszolgálni másodpercenként.

Érdekes kérdés, hogy ebből mennyi is az elég, vagy legalábbis az elvárható, ha egy saját alkalmazást tesztelünk. Persze annyi, amennyi a majdani látogatókat ki tudja szolgálni. 'Educated guess' alapján úgy gondolom, hogy egy jól belőtt, megfelelő cachelést alkalmazó és egy átlagos extranet bonyolultságát felmutató oldalból 50 körül lehet kihozni, de 20-30 még jónak számít. Természetesen ez sokban függ a tesztelendő gép hardverétől is, ezek csak irányszámok.

A tesztelés

A teszteléshez JMeter-t használok, ezzel grafikusan lehet összehúzogatni a teszt lépéseit, valamint az eredményeket is táblázatok és/vagy grafikonok segítségével tudjuk megnézni. A tesztek lelke a Thread Group, itt állíthatjuk be, hogy hány párhuzamos szálon és szálanként hányszor tesztelünk. Ennek a gyerekeként HTTP Request-eket tegyünk le, és állítsuk be a tesztelt URL-eket. Érdemes Assertion-öket adni a kérésekhez, hogy valamilyen szinten a válasz helyességét is meg tudjuk ítélni. Legegyszerűbb a Size Assertion, ezzel már ki tudjuk szűrni, ha mondjuk a terhelésre üres oldalt vagy rövid hibaüzenetet kapnánk vissza. Természetesen nem érdemes a terheléstesztet összetéveszteni az funkcionális teszteléssel, itt feltételezzük, hogy maguk a funkciók működnek.

Érdemes Controller-be venni fel a kéréseket, pl. egy Random Controller-be. Ezzel a benne lévő lekérések közül az egyik fog csak végrehajtódni, de több szál esetén ezzel hatékonyan tudjuk szimulálni azt, hogy párhuzamosan több oldalt is látogatnak. Végül egy Assertion Results-ot és egy Aggregate Report-ot tegyünk le, ezeket figyelve majd láthatjuk az eredményeket, valamint, hogy bukott-e meg az ellenőrzésen valamelyik válasz. Ezután Start, majd idővel megkapjuk az eredményeket. Futás közben érdemes figyelni a rendszer memóriahasználatát, az egyes folyamatok processzorhasználatát, valamint az I/O-t is. Ezzel ki tudjuk szűrni, ha pl. adatbázishoz túl sokszor fordul, vagy ír a lemezre.

A Glassfish minden felhasználóhoz rendel egy session-t, melyekből tesztelés alatt túl sok is létrejöhet, így ronthatja a mért teljesítményt. Ennek elkerülésére maximalizáljuk a számukat, vagy az elévülési idejüket vegyük le.

Ez a tesztelés nem tartalmaz bejelentkezést. Ehhez fel kell vennünk egy Cookie Manager-t, valamint szimulálnunk kell a belépést, valamint a későbbi felhasználói akciókat. A POST-okat kinyerhetjük a böngészőből pl. Firebug-gal, így kényelmesen felépíthetünk bonyolultabb bejárásokat is.