- curl-loader
- httperf
- Siege
- Tsung
A szerző szerint az igazán jó megoldás a fenti programok bizonyos sorrendben való egymás utáni használata, az egyszerű tesztektől haladva a bonyolultabbakig. Az irás könnyed, elsősorban érdeklődő kezdőknek és amatőröknek szól. A cikket megtalálod itt.
- A hozzászóláshoz be kell jelentkezni
- 5697 megtekintés
Hozzászólások
Nekem volt szerencsém az Apache jmeter programjához...
http://jakarta.apache.org/jmeter/
A program által indított proxy-n keresztül több gépről, különféle böngészőkből végigkattingatva (bejelentkezés, stb...) a vizsgált oldalt az elkövetett műveleteket rögzíthetjük.
Majd a megadott paraméterek szerint (kliensek száma, stb...) a korábban rögzített böngészést visszajátsza a vizsgált szervernek. Arra is van lehetőség, hogy a jmeter által irányított, több dedikált gép végezze a terheléspróbát.
--
maszili
- A hozzászóláshoz be kell jelentkezni
+1 Siege-nek (régebben nyúztam)
- A hozzászóláshoz be kell jelentkezni
kar h a kliens performanszot merik ezek a toolok
#toy like ppl make me boy like
- A hozzászóláshoz be kell jelentkezni
Saját tapasztalataim alapján a webszerverek tesztelésének nem az a nehéz része, hogy valamilyen módon HTTP(s) kérésekkel bombázzuk a szervert. Ez egyszerű, és mind a cikkben említett toolok, mind mások (jmeter, az apache ab programja, stb.) remekül használhatóak hozzá.
A nehéz rész ott kezdődik, hogy:
- meghatározzuk, hogy mit és miért tesztelünk (nem mindegy, hogy azt szeretnénk látni, hogy az apache-unk hány statikus HTML oldalt tud kiszolgálni másodpercenként, vagy azt, hogy milyen nagyságrendű sessiont képes párhuzamosan kiszolgálni a tomcat-hibernate-postgresql alapú rendszerünk)
- megpróbáljunk úgy tesztelni, ahogy a valóságban érkeznének a kérések (pl. a proxy alapú visszajátszások, amennyiben részük egy login a webes rendszerbe teljesen irrelevánsak akkor, ha csak egyetlen felhasználó kéréseit játsszák vissza ezer szálon kétmilliószor)
- tudjuk értelmezni a tesztelések eredményeit (nem mindegy, hogy mi a lassú: a webszerver, a rajta futó alkalmazás, az adatbáziskezelés, vagy valami más).
Általában elmondható, hogy a legritkább esetben okozza az alacsony teljesítményt a webszerver maga, illetve ha az okozza, akkor pillanatok alatt javítható a dolog a megfelelő szálszám és használható memóriaméret beállításával. Cserébe sokkal-sokkal nehezebb megtalálni mondjuk egy HUP kaliberű oldal esetében, hogy melyik kis dobozka adatbázishoz fordulása okozza az oldal töltésének 0.1 másodperces késését, amitől viszont lassú az egész oldal (szerintem jeleneleg nincs ilyen bottleneck a HUP-on, csak a példa a dolog).
- A hozzászóláshoz be kell jelentkezni
És még egy erős buktató: általában nehéz olyan kliens produkálni, ami képes megfelelően nagy terhelést előállítani. Ha statikus HTML oldalból egy mérés 600/sec teljesítményt mutat, akkor lehet, hogy azért van, mert a tesztelő kliens ennyi kérést tud elküldeni egy másodperc alatt, a szervernek meg bőven van ideje malmozni közben. Hasonlóan lehet szűk a hálózat is a kliens és a szerver között...
- A hozzászóláshoz be kell jelentkezni
Ezért vannak erre kifejezetten céleszközök pl Spirent, Ixia.
Pl a Spirent egyik legkisebb doboza:
http://www.spirentcom.com/enterprise/products/avalanche/a2500/specs.asp
Egyébként meg a kliens teljesítményét is meg kell határozni, aztán megszorozni annyival a kliensek számát amennyi kell :)
- A hozzászóláshoz be kell jelentkezni
az apache ab hasznalhatatlan valodi tesztelesre a buta sorositott mukodese miatt :/
- A hozzászóláshoz be kell jelentkezni
siege támogatja a proxy-s adatgyűjtést, sproxy cuccával. Abban egyetértek, az nem szimulálja a több különböző user bejelnetkezését, különböző session-ökben különböző cselekmények kivitelezését, de erre a több kliensre elosztott tesztelés tőbb recorded sessionel talán megoldás.
- A hozzászóláshoz be kell jelentkezni
Szia!
Én a JMeter-t ajánlanám! Nemrég készítettem egy 3 részes magyar nyelvű tutorialt a használatához!
Balázs.
- A hozzászóláshoz be kell jelentkezni