glassfish + mysql teszteles

a mysql igy lett forgatva:

CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql51 --enable-assembler

(azert nem forgattam teljesen statikus binarist, mert az uj glibcvel ezt nem lehet megtenni, csak ha azt is ujraforgatja az ember, amihez nem volt kedvem]

hogy is teszteltem? paraszt modjara. irtam egy nagyon egyszeru J2EE appot, amiben egy entitas volt csak definialva, majd csinaltam egy webszervizt, ami a bejovo parameterek alapjan letrehoz egy ilyet, es le is persisteli. az appszerverben XADataSourceal konfigoltam fel a mysqlt (ne probaljatok a legujabb JDBC driverrel, nem fog menni, bugos. toltsetek le innen a jo jdbc drivert, ezzel megy az XA (gentoon buildeltem egyel reggebit (talan 5.0.8?), ez az a jar).

irtam egy nagyon egyszeru tesztert is (ez itten elerheto), ami nem csinal semmit, csak egy szalon futva N-szer meghivja ezt a webszervizt, tovabba irtam egy egyszeru scriptet (ez meg itt), hogy ebbol elindithassak x darabot.

elinditottam egyik tesztgepen es csak egyet, mit latok? 70req/s. hat mondom ez nem tul sok, nezzuk mi van, ha 20at inditok el (x.sh alapbol ennyit csinal). ez 37/teszt lett, ami ugye 20*37 azaz 740 keres, ami nem rossz, viszont a db szerver loadja meg mindig sehol nem volt.

akkor fogjunk 5 klienst, es inditsunk el rajtuk 20at darabonkent. ez 9keres/s/teszterre jott ki, ami osszessegeben ugye 5*20*9 keres, ami 900.. hat, legalabb nem csokkent, viszont en nagyon elegedetlen voltam, ugyanis se az appszerveren, se a db szerveren nem volt load, en meg szeretem ha kivan hajtva a gep.

hat akkor tuningoljuk az appszervert egy picit, biztos azzal van a baj. ehez elosszor is fogtam, es felemeltem a connection pool limitet (alapbol 32 a max connection, es 8 az init, a lepeskoz meg 2, en ezt felemeltem 32 min connectionre, 128 maxra, es 8 lepeskozre), majd felemeltem a http listenernel a threadek szamat (ezt procikszamanyira ajanljak, en 2*coreokszamat raktam).

elinditottam az egyik kliensen a progit husszor, es mit latok? 90keres/s.. hat ettol sem estem hanyatt. megneztuk mennyire skalazodik, 5 klienssel futtatva 15keres/s lett az eredmeny [ami ugye 5*20*15, ami 1500req/s, az mar nem olyan rossz]

viszont meg mindig volt tartalek az appszerverben is boven, illetve a db szerverben is.

ilyenkor jott az erdekesebb dolog: ha nagy gepre telepitunk appszervert, akkor ugy ajanlott, hogy 2 coreonkent 1 appszerver, hogy jobban ki lehessen hasznalni a gepet. fogtam 4 glassfisht, felraktam, majd ele raktam egy lighttpd -t (rogton fogtam egy bugot a legujabb, 1.4.20-asban: mod_proxynak nem megy az RR, mert rossz a kod, hiaba probaltak javitani, nem sikerult. gyorsan megszakertettuk a lighttpd-s stbuehler -el, mar javitva van az svnben ha minden igaz (igen, javitva)), es megkuldtem proxyn keresztul.

mostmar jobban ment a teszt, sikerult 2.5k req/sig felkuzdenem, es meg volt boven szufla a rendszerben, de mivel 8ra megyek be az egyetemre, igy nincs tobb idom tesztelni. majd folytatom ha beertem a melohelyre. :)

az egesz teszt lenyege egyelore az lenne, hogy kideruljon, hogy mennyire skalazodik nagy boxokon a mysql, ehelyett folyton GF-bottleneckekbe utkozok, amit nem igazan ertek. jo, szerializalni kell csomot, de nem hiszem, hogy ne lehetne kevesebb eroforrassal. a mysql teljesitmenyen sokat javithat elvileg mind a google patche, mind Yasufumi patche (a teljes bugreport), mind a perconas sracok egyeb fixei.

ja, mielott elfelejtem: a 2k req kozben olyan 50% volt a cpu hasznalat, ami azt jelenti, hogy meg 15x ennyi terhelest elvisz. ami nem rossz. (felvete, hogy linearisan skalazodik, ami ugye nem trivialis dolog, es pont ez az, amit tesztelni akartam, csak nem olyan egyszeru ez).

ha van valakinek felesleges vasa amugy kolcsonbe, szoljon nyugodtan (legkondicionalt szerverterembe tudom oket rakni, ott van ket ajtora tolem, viszont vagy csak 1Us >=2 proc gepek erdekelnek, vagy akarhany U-s >=8 proc gepek, az elozoeken futna a teszt-kliens, az utobbiakon pedig mysql, lehetne nezni hogy skalazodik)

ha megtalalom az idealis architekturat, hogy kitoljak egy 8 procis tuningolt db szervert (persze nem default konfiggal futott, hanem amit direkt erre optimizaltam), kiprobalom oracle 11g -vel is illetve postgressel. [mivel ugye JPA -n keresztul erem el, igy tokmindegy mivan alatta.]

a hetvege cehje $29.98, nekem ennyit megert, hogy teszteltem.

ja, es a Coherencere megint nem volt idom... szoval folyt kov. :)