[J2EE]Performance WebService via Axis & EJB's naar MySQL

[kasper_vk]

Wij zijn een nieuwe versie voor een webservice aan het schrijven, omdat de oude tegen zijn dak zit qua performance & schaalbaarheid.

De (nieuwe) opzet is als volgt:
1 een (Axis) webservice ontvangt de call en encapsuleert de WS data klasses naar 'eigen 'domein klassen
2 er wordt (met die eigen klassen als parameters) een call gedaan naar een Stateless Session Bean (JBoss is de applicatieserver)
3 ieder zo'n EJB heeft een eigen database-connectie met een set prepared statements; de bean vult de juiste statement in en vuurt het verzoek af
4 MySQL (op een aparate machine) doet z'n ding en geeft een antwoord terug

We testen de gehele opzet met een zelf geschreven java client, welke meerdere concurrent threads aan het werk zet om calls af te vuren op de webservice. Er wordt voorlopig alleen getest met opvragingen waarvan we weten dat er in de database gegevens gevonden worden.

Het Probleem
.. is de performance. Die is niet bevredigend; maximale throughput aan de client kant is zo'n 25 call per seconde bij 10 concurrent sessies (is het maximaal haalbare).
Maar het vreemde is: geen van de systemen zit tegen z'n dak qua CPU load, de gegenereerde netwerk-traffic is een schijntje t.o.v. de capaciteit en de database staat ook uit z'n nuis te eten. De client PC heeft ook al niets te doen; met meerdere clients wordt (opgeteld) nauwelijks een hogere throughput gemeten.

De laatste 'hoop' was dat de database niet goed in elkaar zat (qua query's of indexen); maar wanneer we de client aanpassen zodat ie direct naar dezelfde MySQL database gaat, wordt de throughput (maximaal) een ruime 3000 calls / sec bij 60 concurrent sessies. Nogal een verschil met de gemeten 20 calls/sec in de complete opstelling! Wij concluderen hier dat de database dus niet de bottleneck is.
Ook hebben we de poolsize van de EJB's en de Http sessions bekeken, maar die staan ruimschoots boven het geteste aantal concurrent sessies.

Mijn vraag aan jullie
hebben jullie ervaring met de gebruikte tools (JBoss, Axis, Stateless EJB's, en/of MySQL) en een idee waar de bottleneck zou kunnen zitten?

Ieder advies of suggestie is welkom!

[Alarmnummer]

1) Pak eens een profiler erbij (JProfiler bv)
2) wat je zou kunnen doen is stap voor stap meer functionaliteit aan te zetten. Dus 1e stap is de webservice laten draaien, maar de call niet doorgeven naar de EJB. Daarna wel de call naar EJB doorgeven maar niet laten saven naar de db. En als laatste ook met de db erbij.

Ik heb zelf geen ervaring met deze combinatie van tools (ik doe niets met EJB).

[Standeman]

Hier gebruiken we ook axis en dat performed op zich prima. Er wordt ook aan encapsulating gedaan naar domain classes en daarna wordt er gezoch in een lucene index.

Een gemiddelde request duurt ongeveer 300 ms en 100 tot 500 concurrent threads zijn geen probleem (nooit verder getest).

Overigens lijkt het me heel stug dat de EJB container van JBoss de schuldige is (ik heb er niet veel ervaring mee, maar ik heb geen problemen mee gehad).

suc6 met uitzoeken

[kasper_vk]

Alarmnummer schreef op woensdag 16 november 2005 @ 17:04:
1) Pak eens een profiler erbij (JProfiler bv)
2) wat je zou kunnen doen is stap voor stap meer functionaliteit aan te zetten. Dus 1e stap is de webservice laten draaien, maar de call niet doorgeven naar de EJB. Daarna wel de call naar EJB doorgeven maar niet laten saven naar de db. En als laatste ook met de db erbij.

Goeie opties, ga ik morgen proberen op mijn werk.
Overigens; een profiler ertegenaan houden, dat leek me in eerste instantie niet zo zinnig, aangezien zowel JBoss als MySQL praktisch geen cpu-load vertonen. Aan wat voor problemen denk je wellicht? Hoedanook verschaft het natuurlijk extra inzicht, dat is altijd waardevol.

Standeman schreef op woensdag 16 november 2005 @ 17:18:
Hier gebruiken we ook axis en dat performed op zich prima. Er wordt ook aan encapsulating gedaan naar domain classes en daarna wordt er gezoch in een lucene index.

Een gemiddelde request duurt ongeveer 300 ms en 100 tot 500 concurrent threads zijn geen probleem (nooit verder getest).

Overigens lijkt het me heel stug dat de EJB container van JBoss de schuldige is (ik heb er niet veel ervaring mee, maar ik heb geen problemen mee gehad).

suc6 met uitzoeken

Prettig om te weten dat Axis geen schlaabaarheidsprobleem vertoont; al kost het serialisen & deserialisen relatief gezien echt enorm veel tijd, is mijn indruk. Maar het schaalt dus goed mee, da's geruststellend.

[misfire]

1. Hoe hoog heb je de web thread pools, EJB pools of database connectiepools staan? Ik ken de default waardes van JBoss niet uit mijn hoofd, maar bij bv. Websphere is die vaak 10. Als de pools vollopen gaat dit ten koste van je schaalbaarheid, je moet altijd minstens 10% vrij hebben, zelfs bij maximale verwachte belasting.

2. Weet je zeker dat je goed meet? Een eigen tooltje is leuk maar een goede load test tool maken is best ingewikkeld. Probeer eens JMeter of een andere bekende gratis tool, daar kun je ook prima web services mee testen, en dan heb je (meestal) een nauwkeurigere meting en meer toeters en bellen.

3. Als er geen duidelijke bottleneck zichtbaar is in de hardware en je pools zijn niet te klein dan heb je waarschijnlijk last van threading issues (overmatige synchronisatie). Een goede profiler (zoals JProfiler) kan dit voor je laten zien. Je kunt ook JConsole of iets dergelijks proberen, waarmee je de meest extreme threading problemen ook kunt oplossen.

[kasper_vk]

misfire schreef op woensdag 16 november 2005 @ 23:16:
1. Hoe hoog heb je de web thread pools, EJB pools of database connectiepools staan?

MaxThreads voor Tomcat staat op 250, maximum size container pool voor Stateless EJB's is 100. En dat terwijl de grens met pakweg 10 threads dus al bereikt is; lijkt me voldoende.

2. Weet je zeker dat je goed meet? Een eigen tooltje is leuk maar een goede load test tool maken is best ingewikkeld. Probeer eens JMeter of een andere bekende gratis tool, daar kun je ook prima web services mee testen, en dan heb je (meestal) een nauwkeurigere meting en meer toeters en bellen.

Klinkt alsof ie vrijwel precies doet wat onze eigen test-tool ook doet, alleen generieker en met meer toeters en bellen JMeter zal ongetwijfelt (nog ) beter in elkaar zitten, al geeft onze eigen tool ook gemiddelden, throughtput, etc. en kan ie ook de resulataten per call opslaan. Voordeel van een eigen test-tool is dat je precies weet wat er gemeten wordt en hoe je de resultaten moeten interpreteren.
Hoeveel ervaring heb je met JMeter?
Ik heb de Building a WS Testplan uileg doorgelezen en het klinkt niet erg moeilijk, maar hoe is de werkelijke leercurve? Hoe lang duurt het voor je in JMeter de eerste test hebt lopen vanaf het moment van downloaden? Ik heb zeker interesse.

3. Als er geen duidelijke bottleneck zichtbaar is in de hardware en je pools zijn niet te klein dan heb je waarschijnlijk last van threading issues (overmatige synchronisatie). Een goede profiler (zoals JProfiler) kan dit voor je laten zien. Je kunt ook JConsole of iets dergelijks proberen, waarmee je de meest extreme threading problemen ook kunt oplossen.

Ik dacht inderdaad ook al aan synchronisatie-issues, al wist ik niet dat je dat met een profiler inzichtelijk kunt maken; omdat Alarmnummer ook al een profiler aanraadt, zal ik dat hier dus zeker gaan aankaarten.

[Verwijderd]

ben ik naief als ik in eerste instantie gewoon aan veel logging statements met timestamps denk?
Dan weet je toch welk deel het traagst is en weet je al waar je alles moet controleren. Dus je webserviceImpl logt de entry en leave en alles ertussen ofzo, daarna in je SLSB ook elke stap laten volgen door een timestamp log en gewoon kijken welke het traagst is.

Hoe groot is je connection pool?

[LAN]

Hoe staat het met je heap size?

Misschien staat je garbage collector continu te ratelen.

[kasper_vk]

Verwijderd schreef op donderdag 17 november 2005 @ 10:24:
ben ik naief als ik in eerste instantie gewoon aan veel logging statements met timestamps denk?
Dan weet je toch welk deel het traagst is en weet je al waar je alles moet controleren. Dus je webserviceImpl logt de entry en leave en alles ertussen ofzo, daarna in je SLSB ook elke stap laten volgen door een timestamp log en gewoon kijken welke het traagst is.

Nee, dat ben je niet; we hebben een log aan de server-kant, die net voordat & net nadat de query uitgevoerd wordt een timestamp maakt. Daarbij wordgebruik gemaakt van System.currentTimeMilles().

Die loggegevens suggereren overigens dat de queries vreselijk lang duren, terwijl de database zelf dus enorm snel reageert wanneer we vanaf de test-client direct naar de database gaan.

Hoe groot is je connection pool?

We gebruiken geen connection pool, maar iedere Session Bean heeft zijn eigen cdb onnectie.
De toepassing is een webservice die enkel opvragingen uit de database doet; de beans wordt gepooled en hebben dus ieder hun eigen connectie met een eigen set prepared statements.
In principe doet de bean niets anders dan op basis van een inkomende datastructuur de juiste query invullen en de resultset weer naar pojo's vertalen en die teruggeven.

Het loskoppelen van de connecties van de beans heeft m.i. alleen maar nadelen; iedere call op de bean heeft altijd een connectie nodig en gebruikt altijd 1 soort query uit een beperkt aantal verschillende soorten. Apart poolen van de databaseconnectie zorgt ervoor dat geen gebruik gemaakt kan worden van prepared statements en dat je feitelijk dubbel pooled: n.l. beans & connecties, terwijl die 1-op-1 gebruikt worden. Met het poolen van de bean poolen we dus impliciet ook connecties.

[kasper_vk]

LAN schreef op donderdag 17 november 2005 @ 11:02:
Hoe staat het met je heap size?

Misschien staat je garbage collector continu te ratelen.

Als dat zo was, zou dan de cpu-load van de JBoss machine niet een stuk hoger zijn? Momenteel is de belasting daar enkele procenten.
Maar om je vraag te beantwoorden : de heapsize is vergoot t.o.v. de default waarde, hoe groot precies weet ik niet.

[Verwijderd]

kasper_vk schreef op donderdag 17 november 2005 @ 11:18:
[...]

Het loskoppelen van de connecties van de beans heeft m.i. alleen maar nadelen; iedere call op de bean heeft altijd een connectie nodig en gebruikt altijd 1 soort query uit een beperkt aantal verschillende soorten. Apart poolen van de databaseconnectie zorgt ervoor dat geen gebruik gemaakt kan worden van prepared statements en dat je feitelijk dubbel pooled: n.l. beans & connecties, terwijl die 1-op-1 gebruikt worden. Met het poolen van de bean poolen we dus impliciet ook connecties.

probeer hier eens mee te spelen:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigDataSources

# <prepared-statement-cache-size> - the number of prepared statements per connection to be kept open and reused in subsequent requests. They are stored in a LRU cache. The default is 0 (zero), meaning no cache.
# <share-prepared-statements> - (b) with prepared statement cache enabled whether two requests in the same transaction should return the same statement (from jboss-4.0.2 - default false).

[misfire]

kasper_vk schreef op donderdag 17 november 2005 @ 09:15:
Klinkt alsof ie vrijwel precies doet wat onze eigen test-tool ook doet, alleen generieker en met meer toeters en bellen JMeter zal ongetwijfelt (nog ) beter in elkaar zitten, al geeft onze eigen tool ook gemiddelden, throughtput, etc. en kan ie ook de resulataten per call opslaan. Voordeel van een eigen test-tool is dat je precies weet wat er gemeten wordt en hoe je de resultaten moeten interpreteren.
Hoeveel ervaring heb je met JMeter?

Ik gebruik JMeter ongeveer 2 jaar nu voor alle load-testen die ik uitvoer. De waardes die JMeter laat zien zijn redelijk vanzelfsprekend, en er zijn verschillende nuttige manieren om de getallen zichtbaar te maken.

Ik heb de Building a WS Testplan uileg doorgelezen en het klinkt niet erg moeilijk, maar hoe is de werkelijke leercurve? Hoe lang duurt het voor je in JMeter de eerste test hebt lopen vanaf het moment van downloaden? Ik heb zeker interesse.

Een eenvoudige eerste test heb je in een half uur wel in elkaar zitten als je één van de tutorials volgt. De basis is vrij eenvoudig. Het wordt iets lastiger als je bijvoorbeeld csv testdata in gaat lezen om 20.000 verschillende zoekbevragingen na te bootsen, maar ook dat lukt je meestal na een dagje wel. Het clusteren van test-clients is een broodnodige feature als je serieus load wilt gaan testen, omdat 1 client pc dan gewoon niet genoeg load kan genereren. Vroeger was JMeter op dat onderdeel nogal lastig, maar nu dat ook een stuk simpeler.

JMeter is dus zeker een aanrader, net als JProfiler trouwens.

[kasper_vk]

Standeman schreef op woensdag 16 november 2005 @ 17:18:
Hier gebruiken we ook axis en dat performed op zich prima. ...
Een gemiddelde request duurt ongeveer 300 ms en 100 tot 500 concurrent threads zijn geen probleem (nooit verder getest).
...

Een week verder hebben we inmiddels de oorzaak van de problemen gelocaliseerd: Axis.
Dit hebben we gedaan door combinaties van de suggesties hier: zowel timers plaatsen langs de 'verwerkingsketting' als door de ketting steeds een beetje in te korten en dan de overall performance te meten.
Wanneer we i.p.v. Axis (1.1) een servlet gebruiken (met als heengaand bericht een http-post met wat parameters, dus geen xml), daarvanuit dezelfde EJB aanroepen en vervolgens een xml antwoord-teruggeven, performt het als een jachtluipaard.

Daarnaast ontdekken we, wanneer we zowel de eenvoudige servlet als Axis (in aparte sessies natuurlijk) enorm onder druk zeten, dat er in de opstelling met Axis time-outs en connect-exceptions optreden, terwijl dat bij de servlet-opstelling niet gebeurd.
We hebben daarnaast de oplangs uitgekomen Axis 1.3 gebruikt: deze werkt over het geheel trager (zowel client-side als server side), maar lijkt wel iets beter op te schalen. Ook hier treden de time-outs en excpeties op, maar in iets mindere mate.
Op internet is helaas weinig te vinden over configuratie / tuning van Axis; zo ontdekten we dat Axis 1.3 meer validatie toepast (in bv. het retourbericht) dan 1.1, maar nergens is te vinden of die validatie uitgezet kan worden. Weet iemand uit ervaring hier wellicht meer van?

Standeman, hebben jullie ook soortgelijke problemen ervaren? Kun je iets meer vertellen over die load van 100 ~ 500 concurrent threads & de gebruikte opstelling?

Heeft iemand anders soortgelijke ervaringen met Axis?

Wanneer we zouden overwegen om Axis eruit te schoppen, dan denken we in eerste instantie aan het schrijven van een servlet die zelf de parsing, bean-aanroep en serialisation van het antwoord doet, maar da's nogal arbeidsintensief (en weinig herbuikbaar zonder dat het te veel ontwikkeltijd kost).

PS: gebruik van JMeter en profilers heb ik er hier niet doorgekregen, omdat dat te veel (leer)tijd zou kosten. Jammer

[ Voor 5% gewijzigd door kasper_vk op 24-11-2005 14:00 ]

[Alarmnummer]

Je zou misschien eens kunnen kijken naar XFire.

Check verder deze weblog eens over benchmark XFire vs Axis.

Een van de ontwikkelaars van XFire (Arjan Poutsma) is trouwens werknemer bij interface21 (het bedrijf achter Spring).

[ Voor 28% gewijzigd door Alarmnummer op 24-11-2005 14:17 ]