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
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
Comment