Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web development, networking and server security. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Poređenje performanse J2EE Servera

Uvod


Ako ste pročitali prethodnu verziju našeg izveštaja, možda biste želeli da pređete direktno na odeljak Promena radi rezimea toga kako se naša metodologija testiranja promenila za ovu verziju.

Standardizacija servera primene ( application server), zahvaljujući Sun-ovim J2EE specifikacijama, raširila je čitavo bogatstvo implementacija. Ima ponuda od velikih igrača kao što su Sun, IBM, BEA i Oracle,kao i brojne ponude od low-cost prodavaca i zajednice “otvorenog izvora” .

Kao i većina developera, ja učestvujem u brojnim tehničkim forumima i mailing listama. Periodična tema na servlet-razvojnim(servlet-development) forumima je “Koji J2EE server treba da koristim za moju primenu na bazi servlet-a( servlet-based application)?” Postoje brojni kriterijumi za odabir servera:laka instalacija,kvalitet dokumentacije,pouzdanost,cena i performansa.Neki od ovih aspekata su odmah vidljivi procenitelju;ali izgleda da performansa proizvodi mnogo diskusije sa primetnim manjkom činjenica.Nakon brze pretrage,bio sam iznenađen da je malo korisnih testova performanse(benchmark) bilo objavljeno u poređenju sa servlet performansom popularnih low-cost servera.

SPECjAppServer2002


Ubrzo nakon objavljivanja verzije v1.0 ovog izveštaja, Korporacija za procenu standardne performanse (Standard Performance Evaluation Corporation) je objavila SPECjAppServer2002, "klijent/server test preformanse(benchmark) za merenje performanse Java Enterprise servera primene(Java Enterprise Application Servers) uz korišćenje pod-seta J2EE APIs u kompletnoj end-to-end web aplikaciji." Detalji i rezultati ovog testa su dostupni na http://www.spec.org/jAppServer2002/ . Po mom mišljenju, ova specifikacija testa ima malo vrednosti za male projekte,obzirom da ne testira sve servere na istom hardware-u – što iskrivljuje rezultate prema prodavcima koji biraju da osnuju ekstravagantne hardware konfiguracije. Sa druge strane,benchmark je namenjen da se fokusira na ukupnu cenu - transakcije “za dolar” u investiranju. Za široku primenu, ovo bi mogla da bude veoma vredna informacija. Bilo bi zanimljivo testirati ovaj benchmark u podešavanju sličnom ovom izveštaju: svi serveri koji rade u standardnim konfiguracijama na istom hardwaer-u. Na žalost, cena licenciranja SPECjAppServer2002 servera prevazilazi naš budžet.

Motivacija


Moj lični kuriozitet bio je faktor driving-a,koji je i započeo ovaj napor.Razvoj i testiranje za ovaj izveštaj su finansirani isključivo od strane naše kompanije kao napor da se uzvrati doprinos Java zajednici od koje smo toliko dobili.

poricanje i otkrivanje:

  • Sve izjave i mišljenja sačinjena u ovom dokumentu pripisuju se isključivo autoru.Ona ne predstavljaju poglede i/ili politiku Web Performance, Inc.-a.

  • Web Performance, Inc. koristi Tomcat za pokretanje internog Wiki-a i nekih nizova programa za testiranje.

Serveri


Nekoliko servera je originalno bilo namenjeno za ovaj izveštaj, ali rezultati su zadržani,jer njihove dozvole zabranjuju objavljivanje testova performanse bez dozvole.Tražena je dozvola od ovih prodavaca,ali još uvek nije odobrena.Nadamo se da ćemo ih uključiti u izveštaj ubrzo nakon što dobijemo dozvolu da objavljujemo.Ovi serveri uključuju:

  • Sun Java System Application Server

  • BEA WebLogic Application Server

  • Pramati Server

Specijalnu zahvalnicu


Želeo bih da proširim specijalnu zahvalnicu na one kompanije koje ne uvode nerazumne restrikcije na objavljivanje testova performansi (benchmarks) (Caucho, IronFlare i IBM). Jedno otvoreno, informisano tržište je blagotvorno za sve nas uključujući konkurente. IBM zaslužuje da ih posebno pomenem zbog njihove veoma jasne i veoma fer klauzule.Da parafraziram,ugovor o licenci navodi da testovi performansa(benchmarks) smeju biti objavljeni ukoliko su propraćeni punim otkrivanjem metodologije testiranja.Pored toga,stoji i “ako testirate(benchmark) naš proizvod,slažete se da mi možemo da testiramo vaš”.Nisam pravnik,ali po mom mišljenju,ovo je veoma pošten način da se izbore sa konkurentima koji bi mogli da pokušaju da zloupotrebe fleksibilniji ugovor o licenci.

Ciljevi testiranja


Svrha nije da se objavi 'pobednik' – to je najbolje prepustiti publikacijama koje traže prihod od reklame.Umesto toga,ovaj izveštaj pruža veliki broj različitih merenja performanse servera pod teretom učitavanja.Podaci su predstavljeni uporedo sa nekim analizama i komentarima.Biranje pobednika je prepušteno čitaocu.

Scenario upotrebe


Ovaj izveštaj je namenjen proceni servlet performanse samostalnog servera. Očekuje se da bude primenjiv na malim-do srednjih projekata koji razvijaju primene u sredinama kao odseci i male korporacije.Nije namenjen da predstavlja performansu servera koji je visoko optimiziran da bi postigao maksimum performanse zbog jedne naročite aplikacije.

Poteškoće Benchmarking-a(testiranja performanse)


Jedna stara izreka kaže: "Postoje laži, proklete laži i benchmarks!". Potpuno svesno opasnosti od pogrešnih testova, nema očekivanja da će se ovaj izveštaj odraziti na performansu bilo koje naročite aplikacije,ili klase aplikacija, što bi se možda razvilo u realnom svetu.Svaka zadata aplikacija će naglasiti različite delove servera.Neke aplikacije će bolje raditi na nekim serverima nego druge.Nadam se da će ovaj izveštaj obezbediti podatke koji će čitaocu pomoći da izmeri balans(trade-off) performanse kod različitih servera.

Sirovi(raw) brojevi naspram Relativne performanse


Obzirom na varijabilnost primene i hardware konfiguracije, ovaj izveštaj vam ne može reći sa koliko će korisnika vaša aplikacija moći da rukuje u vašem okruženju (zbog čega mi prodajemo proizvod za baš tu svrhu!). Ovaj izveštaj će proizvesti brojeve kao što su hits/sec i prosečno trajanje stranice,ali sirovi brojevi imaju malu vrednost sami po sebi.Samo kada se statistika uporedi naspram onoga što drugi serveri rade,oni obezbeđuju vredan uvid na osnovu kojeg se izvodi sud o performansi.

Nekima će se učiniti očiglednim, ali važno je naglasiti ovu poentu: Ako podaci za ovaj test pokazuju da Server X može da ispuni 200 hits/sec sa prosečnim trajanjem ispod 2 sekunde, nema korelacije sa brojem hits/sec-a za koji će vaša aplikacija biti sposobna. Ovde predstavljeni podaci za Server X su korisni SAMO za poređenje naspram podataka za Server Y i Server Z, pod istim uslovima testiranja naše test laboratorije. Dodatno, molimo da primite k’ znanju da hardware korišćen za server tokom trajanja ovih testova (pogledajte Hardware Configuration, dole) ni po čemu nije konfiguracija -umetničko delo.

Out-of-the-box performansa


Korisno je znati kako će ovi serveri dejstvovati (perform) odmah nakon instalacije. Veliki broj projekata nemaju stručnosti ili resursa da izvedu prošireno podešavanje performanse.Testovi se izvode na svakom serveru u njihovoj standardnoj(default) konfiguraciji nakon instalacije. (pogledajte poglavlje Metodologija).

Reproduktivni rezultati


Bez obzira kakao je ovo testiranje izvedeno, neko će uzviknuti "Faul igra!" Primarni cilj ovog napora je test koji se lako duplira od strane bilo koga ko želi da pokuša.Nema sumnje da tačni brojevi neće biti duplirani,obzirom na razlike u hardware-u i tehniku merenja,ali relativne razlike između servera bi trebalo da budu reproduktivne.Svi materijali koji se odnose na ovaj izveštaj su dostupni u poglavlju Naknadni materijali (Supplemental Materials) .

Fajl koji sadrži detalje scenarija o upotrebi,konstrukciju skripti testova i rezultate testova dostupan je ovde (20MB). Ovaj fajl može da se koristi sa kopijom evaluacije software-a testiranja,Instruktor web performanse (Web Performance Trainer) , u cilju provere ovih detalja. Međutim, licenca za evaluaciju je limitirana na 10 simultanih korisnika; stoga serveri ne mogu biti značajno naglašeni uz licencu za evaluaciju.Ukoliko su vam dostupne druge alatke za učitavanje testova,rezultati bi trebalo da budu reproduktivni kod onih alatki koje imaju informacije koje smo dali.Ako naiđete na teškoće pri reprodukovanju naših rezultata,molimo,kontaktirajte nas.

Servlet aspekti


Razumno je očekivati da će različiti server u različitim aspektima briljirati u izvršenju servlet-a.Ovaj izveštaj uključuje ove aspekte u testove:

  • prosto servlet izvršenje

  • opsluživanje statičkih fajlova (static file serving)

  • praćenje sesije (session-tracking)

  • skladištenje i povlačenje podataka sesije (storing and retrieving session data)

Testovi


Korisnička scenarija


Uprkos činjenici da bilo koji test performanse može da posluži samo kao približavanje slučaju upotrebe u stvarnom svetu,bilo je važno izabrati scenarija za korisnike koji su bar iz daleka slični vrsti upotrebe koja će biti tipična u proizvodnom razvoju.Statistika servera za naš sopstveni websajt je dala inspiraciju. Nakon detaljnih analiza putanja i stranica koje smo prešli na našem websajtu,analizirano je i nekoliko opštih websajtova (yahoo, amazon, itd.).Za izveštaj je izabrano tri scenarija za korisnike:
scenario duration # of pages page sizes # resources (images, etc) resource sizes (bytes)
Kratki - predstavlja frekventno-korišćene stranice (to jest home stranice i korporativne portale) i obeležene (bookmarked) stranice koje se povremeno proveravaju 10 sec. 1 60k 30 500 (x15)
2,500 (x10)
5,000 (x4)
10,000
Srednji - predstavlja kratku operaciju na websajtu (to jest brzu pretragu proizvoda ili proveru statusa otpreme nekog e-commerce(elektronsko tržište) sajta) 1 min. 5 60k
40k
20k (x3)
50 500 (x27)
2,500 (x14)
5,000 (x4)
10,000 (x5)
Dugi - predstavlja duge, zapetljane operacije na websajtu (to jest postavljanje reda i unos informacija o plaćanju i otpremi) 3 min. 20 60k (x4)
40k (x4)
20k (x12)
125 500 (x72)
2,500 (x29)
5,000 (x4)
10,000 (x20)

Scenarija uzimaju u obzir zajedničku websajt imovinu:Prva stranica sadrži puno slika,od kojih se mnoge ponovo koriste na budućim stranicama.Pretpostavljajući da je skrivena memorija (cache) na pretraživaču (browser) osposobljena,ovi izvori neće biti ponovo traženi.Zbog ovoga Kratki scenario sadrži 30 izvora na samo jednoj stranici,a Srednji scenario sadrži samo malo više izvora (50) na 5 stranica.

Korisnička distribucija


Na osnovu distribucije posmatrane u okviru naše statistike servera,izabrali smo distribuciju scenarija (dole,sredina).Tokom simulacije, svaki virtuelni (simulirani) korisnik će u više navrata izvršiti pojedinačni scenario,sve do kraja testa.Tek nakon nadoknade za razlike u dužini svakog scenarija,može se izračunati konačna korisnička distribucija (dole,desno).
scenario scenario distribution user distribution
Short 40% 5%
Medium 35% 30%
Long 25% 65%

Distribucija protoka(Bandwidth distribution)


Javni websajtovi i intranet aplikacije vide izrazito različite distribucije korisničkog protoka.Za javne websajtove,tipične su konekcije od 56k do 1Mbit-a. Za intranet aplikacije,uobičajene su od 10Mbit-a do 100Mbit-a (deli se(share)protok).Protok od 1Mbit-a po korisniku je selektovan za svrhe simulacije.Protok je limitiran za svakog virtuelnog korisnika putem alatke za testiranje.

Primite k’ znanju da, sa protokom od 1Mbit-a po korisniku na mreži od 100Mbit-a,ne može biti podržano više od 100 korisnika koji koriste svoj puni protok (uz pretpostavku 100% efikasnosti mreže - što Ethernet ne može da postigne). Kako god, sva ova scenarija sadrže značajno ‘vreme za razmišljanje’ (vreme između stranica) koje dopušta da više od 100 korisnika iskoristi protok od 100Mbit-a.Nijedan od servera nema kapacitet da omogući puno zasićenje protoka mreže – i stoga ne utiče na rezultate testa.

Konstrukcija slučajeva testiranja(Test Case)


Test case zahteva servlet koji može da povrati web stranice određene dužine i referenciranje određenog broja spoljnih resursa (za ovu simulaciju se koriste slike).Servlet korišćen u testu obezbeđuje traženu funkcionalnost hard-kodiranu u servlet-u.Izvorni kod(source code) za servlet se može videti ovde.Jednom kada su servlet i neophodni resursi instalirani (putem WAR fajla),test alatka se koristi da interaktivno zabeleži scenarija koristeći web pretraživač.Koristi se Internet Explorer 5.5 ,ali izbor pretraživača koji se koristi da zabeleži scenarija ne bi trebalo da utiče na na test.Svaki scenario je zabeležen tokom gore navedenog trajanja.Alatka za testiranje će simulirati scenario koristeći isto vreme za razmišljanje (odlaganje između stranica/URL-ovi)prisutno tokom beleženja.

Praćenje sesije


Da bismo simulirali način na koji Servlet skladište(Servlet Container) rukuje sa informacijama o skladištu i pristupu sesiji,test servlet upotrebljava sesiju objekta (HttpSession). Radi imitiranja tipične aplikacije,količina informacija u sesiji raste sa dužinom sesije.Na prvoj stranici svakog test case-a,započinje sesija.Za svaku posećenu stranicu,nastaje nasumični string i dodaje se sesiji (HttpSession.setAttribute()). Tada, prelazi se lista atributa u sesiji i svaki atribut uključen u povraćenu stranicu. and each attribute included in the returned page. Osposobljeni su “kolačići”(cookies) u pretraživaču,obzirom da je to najčešća upotreba u uslovima realnog sveta.

Kompletan WAR fajl raspoređen na serverima je dostupan ovde .

Metodologija


Software testiranja


Testovi su izvedeni sa Web Performance Trainer-om 2.7 (beta 5 – izrada(build) 506).

Hardware konfiguracija


Obzirom da se svaki server pokreće na istoj mašini, nebitno je koristiti određeni hardware.Ali obzirom da će neko pitati: to je Dell PowerEdge 300 server (850MHz PIII, 512M RAM). Pošto će najčešći raspored za ove servere biti Windows,serveri će raditi na Windows 2000 Server-u, Service Pack 2. Primite k’ znanju da nas je Websphere instaler upozorio na zahtev za radom na Windows 2000 Service Pack 4-u. Server je do otada razrađen(upgraded) i Websphere test ponovljen – nije bilo primetnog efekta na rezultate.

Mašine koje proizvode učitavanje(load-generating machines) se pokreću na višestrukim računarima u našoj test laboratoriji koja operiše u Windows-u 2000 i XP-u. Mašine sve imaju Ethernet adaptere od 100Mb-a.

Generatori učitavanja(load-generators) i serveri su povezani putem Netgear FS524 Fast Ethernet Switch-a. Za vreme trajanja testova, ova mreža je izolovana od svih drugih mreža.

Instalacija, konfiguracija & pokretanje servera


Serveri su svi testirani u svojoj standardnoj(default) konfiguraciji.

Ako je paket za instalaciju servera upakovan sa JVM-om, onda je korišćen. Ako zahteva upotrebu spoljnog JVM-a, Sun JDK 1.4.2_03 je korišćen.

Detaljni koraci korišćeni za instaliranje, konfiguraciju i pokretanje svakog servea su navedeni ovde.

Kada je server jednom pokrenut, servlet korišćen za testiranje je ispunjen za minut,da verifikuje ispravnu konfiguraciju,kao i da osigura da je servlet učitan i započet pre početka svakog testa.

Pokretanje testova


Test se pokreće u propinjućem maniru,dodajući 50 dodatnih virtuelnih(simuliranih) korisnika u nasumičnim intervalima svakog minuta,sve dok se test ne dovrši. Podaci se sakupljaju i sabiraju putem test alatke u intervalima od 10 sekundi.

Završetak testa


Svaki test je završen kada je server prevazišao maksimum kapaciteta. Kada server dostigne svoj kapacitet, počeće da odbija konekcije. Kada brojač grešaka prevaziđe 3000, test se zaustavlja.

Merenja


Test alatka izračunava nekolicinu metrike na svakom URL-u u testcase-u, kao dodatak stranici, scenariju I ukupnoj statistici testa.Ova overall test statistics. Ova statistika je uzorkovana u intervalima od približno 10 sekundi.Zarad uprošćavanja,fokusiraćemo se na pojedinačnu stranicu kao indikator za ukupnu performansu,dodatno nekolicini ukupne statistike testa.

  • Korisnici: Broj korisnika koji su simulirani. Ovo kontroliše software za učitavanje testova (load-testing software).

  • CPU %: upotreba CPU-a, kao što pruža Windows. Ova vrednost je momentalni uzorak u svakom periodu (koji će težiti da ga učini bučnijim od druge metrike).

  • Hits/sec: Broj HTTP transakcija uspešno izvršenih tokom perioda uzorka.

  • Prosečno trajanje stranice: Prosečno trajanje uspešnih transakcija web stranice (naročito prve stranice kratkog scenarija).

  • Greške: Ukupan broj detektovanih grešaka.
Primite k ‘ znanju da,obzirom na nasumičnost neodvojivu od testa i efekte mernog uzorkovanja,mali vrh i doline na mapama nisu značajne. Sveobuhvatni trend je ono što je važno.

Promene od prethodne verzije (v1.1)


Promene od v1.1 do v2.0:

  • Korišćenje obejkata sesije – pogledajte gore.

  • Brže učitavanje – Učitavanje na serveru je povećano na brži hod:50 novih simuliranih korisnika dodatih po minute,za 20 više nego u prethodnom testu.

  • Kraći period uzorkovanja – Gore navedene promene su rezultirale u dostizanju vrhunca kapaciteta svakog servera mnogo brže (~10 minuta naspram ~35 minuta). U odgovoru, skratili smo period uzorkovanja sa 60 sekundi na 10 sekundi. Kraći period uzorkovanja može da rezultira u “talasastijem” grafikonu,zavisno od odgovora servera i neodvojive nasumičnosti u testu.

  • Stalne konekcije - Konekcije se drže otvorene i iznova se kroiste za višestruke zahteve,osim ukoliko nisu zatvorene od strane servera.

  • Višestruke simultane konekcije – Svaki virtuelni korisnik bliže imitira pravi pretraživač otvaranjem dve simultane konekcije serveru.

  • Performansa servlet-a se ne testira odvojeno od performanse resursa koji služe static – testcase uključuje oba.

  • Nema podešavanja performanse/konfiguracije dopuštene za bilo koji server.
(pregledajte prethodnu verziju izveštaja)

Rezultati


Vreme učitavanja stranice


Grafikon koji sledi prikazuje Prosečno trajanje stranice kako je izmereno kod svakog servera pod rastućim učitavanjem. Vertikalna osa predstavlja vreme učitavanja stranice,u sekundama.Ovo vreme uključuje HTML iz servlet-a dodatno statičkim resursima.Horizontalna osa predstavlja vreme testiranja,koje je proporcionalno učitavanju na server(jer je broj simuliranih korisnika povećan na konstantan iznos od 50 novih korisnika po minutu).Nacrti koji stoje blizu horizontalne ose pokazuju bolje posmatranu performansu pod učitavanjem.

Tomcat, Orion, Resin i JRun dejstvovali su veoma blizu većim delom testa. Orion je zadržao performansu sličnu vodećima, ali nije opstao tako dugo. Tomcat i Resin su nastavili rame uz rame sa za nijansu boljim vremenom odgovora od JRun-a, koji je test radio za nijansu duže.Jetty i Websphere performansa su izgubili vrednost rano u testu.

Brojanje grešaka


Naredni grafikon prikazuje kumulativni broj grešaka zabeleženih tokom testa na vertikalnoj osi,sa vremenom(učitavanje) na horizontalnoj osi.Ove su greške tipično odbijene od konekcije ili greške zbog neočekivanog zatvaranja utičnice.Nacrti koji se kasnije dižu u testu pokazuju bolju jačinu.

Tomcat i Resin bili su, ponovo, rame uz rame sve do blizu 12-minutne oznake sa JRun-om koji ih je ponovo nadživeo uz malu marginu.Orion je prevazišao limit u sred pakovanja sa Jetty i Websphere-om koji su prevazišli ograničenje u greškama rano u testu.

Hits/sec


Hits/Sec statistika sabira prethodne dve tačke podataka merenjem broja uspešno obrađenih zahteva,po jedinici vremena.Vertikalna osa meri hits/sec dok horizontalna odražava vreme (učitavanje). Viši grafikoni predstavljaju veću ukupnu mogućnost propusnosti(throughput).

Većina servera je pokazala veoma sličnu performansu kroz većinu testova. Websphere je dostigao vrhunac rano u testu. Jetty je išao u korak sa vodećima dok ne prekorači ograničenje u greškama,dok je Orion nastavio da se penje. Tomcat i Resin su demonstrirali vrhunac propusnosti viši od suparnika,iako ih je JRun pratio u stopu.

Individualna performansa servera


Ovaj odeljak sadrži grafikon od nekoliko ključnih parametara za svaki server:
metric trace color scale
Load (users) blue 0 to 1000 (users)
Throughput red 0 to 1000 (hits/sec)
Errors yellow 0 to 10000 (errors)
CPU utilization green scale = 0 to 100 (%)

Većina servera su se linearno popeli sa učitavanjem – kao što je dokazanao sličnošću nacrta učitavanja i propusnosti. Kao CPU najviše tačke na 100%, većina servera je prikazala plato nacrta propusnosti ili ne-linearno uvećanje u greškama u odgovoru na sve veće učitavanje.

napomena: vremenska skala za svaki grafikon odražava trajanje testa za taj server.Svaki server je pokretan zbog različitog trajanja (pogledajte metodologiju).

Tomcat


Orion


Resin


Jetty


WebSphere


JRun

Analize


Većina servera u ovom testu radili su na solidan,predvidiv način – dobro se kotirajući pod rastućim učitavanjem do limita CPU-a. JRun, Tomcat i Resin su iznurili konkurenciju zbog dostizanja maksimuma hits/sec. Tomcat i Resin su pokazali veću propusnost vrha (peak) i manje vreme učitavanja stranice od JRun-a, koji je blago žrtvovao ovu metriku u korist izvršenja većeg učitavanja od drugih. Jetty je potrošio puni CPU malo ranije od vodećih i pokazao bitno veće vreme učitavanja stranice kako se približavao vrhuncu kapaciteta.

Jetty nije iskoristio puni CPU koji mu je bio dostupan u standardnoj(default)konfiguraciji.Ponovo je testiran sa konfiguracijom kod koje je moguće više nizova,rezultati su dostupni u Dodatku 2 .

Orion takođe nikada nije koristio puni CPU koji mu je bio dostupan – što me je dovelo do sumnje, na osnovu rezultata performanse iz prethodne verzije ovog testa,da bi se on nadmetao sa vodećima da je standardna konfiguracija omogućavala servisiranje više simultanih konekcija.Ova teorija je potvrđena dodavanjem Orion konfiguraciji, što je omogućilo Orion-u da preživi test još 90 sekundi, približivši se performansi Tomcat-a i Resin-a. Iz razloga što je ovo izvan smernica testa,rezultati nisu uključeni u ovaj izveštaj.

Websphere, takođe nije koristio puni CPU tokom testiranja, tako das am posumnjao da je spsoban za bolju performansu, takođe. Povećao sam maksimum veličine “bazena niti” (thread pool) (sa 300 na 500). Ovo je rezultiralo kao značajno poboljšanje,kako u vremenu učitavanja stranice,tako i u kapacitetu propusnosti (throughput).Međutim,i dalje bi bilo potrebno još podešavanja da bi se sustigao ostatak grupe.To podešavanje prevazilazi delokrug ovog izveštaja.

Budući pravci


Postoje brojne stavke vredne daljeg testiranja.Na osnovu povratne veze sa zajednicom i dostupnih resursa,nadamo se da ćemo nastaviti da razvijamo ovaj izveštaj da bolje služi zajednici.

  • Bazeni resursa

  • SSL

  • Drugi operativni sistemi (to jest Linux, Solaris)

  • Optimizacija postavljanja servera (zahtevalo bi nekolicinu dobrovoljaca koji imaju iskustva u podešavanju svakog servera)

  • poređenje performanse sa drugim JVMs (IBM, BEA JRocket, i ostali)

  • izveštaj o potpunoj J2EE performansi uz korišćenje Java Adventure Builder Reference Application

Dodatak 1 - Resin konfig.


Brojni čitaoci su ukazali da postoji veoma jednostavna opcija konfiguracije u Resin-u,koja bi mogla da poveća performansu drastično.U resin.conf fajlu,promenite vrednost parametra dependency-check-interval (interval provere zavisnosti) iz standardne vrednosti od 2 sekunde na preporuku proizvođača od 600 sekundi.Nakon ove promene i ponavljanja testa,rezultati su pokazani u dijagramu koji sledi,koji pokazuje da oba testa rade uporedo:



Kao što je očigledno iz sličnosti gore prikazanih grafikona,uticaj usklađivanja ovog podešavanja na performansu je zanemarljiv u ovom naročitom slučaju.Zbog malog broja resursa u ovom testu upoređenim sa projektom velikih razmera,ne iznenađuje što ovo podešavanje nema efekta – nema zaista mnogo resursa za proveru.

Slično tome, rezultati podešavanja vremena isteka cache-a(skrivena memorija) za statičke resurse (uključujući .png fajlove korišćene u našim slučajevima testiranja(testcase)) nisu imali uočljivi efekat na rezultate.

Dodatak 2 - Jetty konfig.


Nakon ponovnog testiranja Jetty-a sa ispravnim fajlom konfiguracije, bilo je vidljivo da je Jetty bio ograničen dizjanom koji mu nikada nije dozvolio da iskoristi punu CPU snagu njemu dostupnu.Rezultati su pokazali da je jedva dostigao 50% CPU iskorišćenja. Neobično kao za kapacitet Jetty-a kada mu je omogućeno da koristi puni CPU,rekonfigurisan je za 150 niti,po preporuci neke čitalačke povratne veze(feedback).Čak i sa ovom konfiguracijom,Jetty performansa je pala daleko od konkurenata i i dalje nije iskoristila pun CPU.Jetty je tada rekonfigurisan da koristi do 500 niti.I dok i dalje nije iskoristio baš sav CPU koji mu je dostupan,ovo je omogućilo Jetty-u da preživi rastuće učitavanje u trajanju sličnom konkurentima,kao što smo videli u prerađenom dijagramu propusnosti,ispod.Propusnost je bila ispod vodećih za oko 20%,ali se pokazalo da se dobro penje,do svog limita.

Feedback(povratna veza) & Komentari


Komentari o ovom izveštaju se mogu postaviti na company blog post .

Istorija verzije


  • v2.3 - email čišćenje (23. jan. ’09.)

  • v2.2 – ponovno testiranje Jetty-a sa standardnom(default) konfiguracijom. Prethodni test je pogrešno koristio fajl konfiguracije iz testiranja verzije v1.0. Pored toga što je zasnovan na fajlu konfiguracije iz prethodne verzije Jetty-a,omogućio je skoro neograničene niti (threads).

  • v2.1 – dodavanje dodatka 1 (6. jul ’04.)

  • v2.0 – uključenje upotrebe sesije, istrajne konekcije, oštrije pojačavanje učitavanja, višestruke simultane konekcije (29. jun ’04.)

  • v1.1 – pravljenje brojeva verzije izraženijim (21. nov. ’02.)

  • v1.0 – prvo javno izdanje (19. nov. ’02.)

  • v0.2 – interni pregled (15. nov. ’02.)

  • v0.1 - interni pregled (8. nov. ’02.)

Dopunski materijali






Published (Last edited): 23-09-2012 , source: http://www.webperformance.com/library/reports/ServletReport/index.html