Performance Issues / Poolprobleme

[DonUschi]

Moin,

ein kurzer Architektur-Überblick:

JBoss1: Soap -> EJB -> DAO (Entitymanager)

JBoss2: XML Schnittstelle -> EJB -> DAO (Entitymanager)

JBoss 1 fragt bei jboss 2 was an, jboss 2 bei 1 und liefert darauf jboss 1 final ne antwort. da hier anscheinend alle auf jeden warten wirken sich die db bzw hibernate-cash zugriffe katastrophal aus.

Ich versuch grad einem/einigen Performance-Problemen auf den Grund zu gehen.

Reines persistieren brauch bei massiver belastung der Schnittstelle ewig. Dazu hab ich nun schon DB connections hochgedreht. Letzter Ansatzpunkt war dann den Stateless Session Beans ne max pool size von 100-500 zu setzen. Das hat es ein bisschen besser gemacht, erklärt aber immer noch nicht warum simple selects nach id oder entityname oder creates 3-10 sekunden dauern.

Fallen euch noch möglichkeiten an wo DB oder Hibernate schwächeln?

Die Testfälle werden mit Jmeter mit 100-500 gleichzeitig gestarteten Threads provoziert.

Bin für alle Hinweise Dankbar.

Schöne Grüße,
Uschi

[ramon98]

Thread-Pool des JBoss zu klein/ausgelastet?

[DonUschi]

unwahrscheinlich, die slowdowns gibt es wirklich immer an der stelle wo EJB's injected/instantiiert/gepooled werden oder hibernate angesprochen wird.

[Frito]

Die Ursache ist oft die DB. Schau dir mal die Statements an und lass dir mal die dazu passend jeweils den explain plan auf der DB anzeigen. Evlt. fehlen ein paar Indizes. Wie sieht es mit Caching in der Persistenzschicht aus? Ist das sinnvoll konfiguriert (1st level und 2nd level) oder werden die Caches sehr oft geleert?

Sonst hilft raten nicht viel weiter. Da brauchst du konkrete Zahlen. Stelle das Logging des JBoss etwas höher. Interssant dürften hier mal alle Ressourcen sein: org.jboss.resource.
Ein Profiler kann dir gute Dienste erweisen. Evtl. reicht schon JVisualVM, JProfiler, YourKit, ...

Mit AppDynamics (teuer und saugut) oder MoSKito (OpenSource und kost nix) kannst du relativ einfach herausfinden, wo genau die Zeit liegen bleibt. AppDynamics kann auch sehr gut Calls über verteilte Systeme auswerten. In deinem Fall ist die Verteilung noch recht übersichtlich, da könnte man darauf verzichten.

[EDIT]
Neben der DB ist auch Marshalling/Unmarshalling oft ein Problem... gerade wenn bei einem Usecase mehrere Remotecalls beteiligt sind.

Und letztendlich ist es evtl. einfach "nur" das ungünstige Design, evtl. im Zusammenspiel mit der Verteilung.