Performance von EJB

[Patrick Keßler]

Hat einer Erfahrung im Bereich EJB auf Appliction Server
wie ist die Geschwindigkeit

[Andreas Ullmann]

Hallo Patrick,<br>
Die Geschwindigkeit ist etwas langsamer als Beispielsweise CORBA. Ich habe kürzlich in einer Bank einen Vergleichstest verschiedener AppServer gemacht. Für den Zugriff auf eine Sybase-Datenbank mit mehreren Zehntausend Datensätzen und das ganze schön verteilt auf mehrere Rrechner über TCP/IP kann man schon mit einer Wartezeit von über einer Minute rechnen.

Das Auslesen von 500 Datensätzen dauert ungefähr 2 Minuten (Inprise) / über 4 Minuten (ProSyst) -- WebLogic knapp 3 Min. bis 4 Min. schwankend.

Alles klar? Oder willst Du noch mehr wissen

[Marc Demme]

Hallo Leute!<br>
Eine deutliche Performanceverbessung kann man durch die geeignete Wahl des Transaktionstyps noch erreichen. Meist empfiehlt der Hersteller des AS einen bestimmten Transaktionstyp. Beim IAS ist dies <b>REQUIRED</b>!<br>
Grus

Hallo<BR>
Nach meiner Ansicht werden die Wartezeiten überwiegend durch den Zugriff auf die Datenbanken verursacht, nicht durch den EJB Container selbst.<BR>
Man kann sich doch auch Anwendungen vorstellen, welche keine Datenbank benutzen!<BR>
Ich habe eine solche Anwendung erstellt, welche über das Internet benutzt werden kann. Sie verwendet den EJB Conainer Gemstone/J.<BR>
Sie können diese Anwendung ansprechen. Ich verweise Sie dafür auf die folgende WebSeite:<BR>
www.schmitther.de/ms.html<BR>
Gruss Hermann Schmit

Hallo,<BR>
zu meinem vorherigen Diskussionsbeitrag möchte ich noch hinzufügen, daß bei mir die Antwortzeit für eine Anforderung unter 0,25 Sekunden liegt.<BR>
Sie können es selbst testen!<BR>
Gruß<BR>
Hermann Schmit

[Volker Kraska]

Hallo,

die Erfahrungen von Andreas Ullmann habe ich auch gemacht. I.a. kann man aber sagen, dass sich die EJB-Technologie nicht anbietet, wenn Massendaten bearbeitet werden sollen. Batchläufe dieser Art wird man nicht mit EJBs realisieren. Ein wichtiges Merkmal ist das bulk-reading, dass der Container verursacht (der Container bietet immer Transaktionssicherheit). Das Konzept der Lightweight-Objekte kann da helfen.

Volke

[Holger Schulz]

Hallo Andreas!

Hast Du vielleicht nähere Informationen zu Deinen AppServer-Tests?
Würde mich sehr interessieren.
[email protected]

Besten Dank
Holger Schul

[Markus Karg]

Um das zu präzisieren: Zumeist ist es nicht direkt der Zugriff auf das RDBMS, das die Performanceeinbußen verursacht, sondern das OR-Mapping. Ich habe das mit IAS und JOnAS getestet und kam bei beiden zum gleichen Ergebnis: Reine Bean-Zugriffe sind sehr schnell, ebenso wie reine JDBC-Zugriffe, aber Beans, die JDBC als Persistenzmedium einsetzen, sind recht langsam. Das darf man aber nicht überbewerten, denn eine nach aktuellen Pattern designte Applikation kann das zumeist ausgleichen

[Christoph Müller]

Ich kann nur Volker Kraska bestätigen und Hermann Schmitt widersprechen. Auch ich habe EJB als Performance-Killer erlebt. Aus diesen Grund und aus einem (zahlungsschwachen) Mittelstands-Bezug heraus habe ich daher auch ein Framework geschrieben, dass auch ohne EJB auskommen kann (mit Tomcat) und ausgesprochen performant ist. Übrigens Open Source: http://freshmeat.net/projects/cameleon

[Andreas Ullmann]

Hallo, <br><br>
ich kann Markus Karg nur zustimmen! Bea zum Beispiel macht auf jede Tabelle ein Select * from um sicher zu stellen, dass auch alle Spalten wie im Deskriptor angegeben existieren. <br><br>
Das änderte sich allerdings mit der Einführung von EJB-QL.<br> Mit der Einführung von EJB-QL sind die Performance-Einbrüche nicht mehr so drastisch. Der Umstieg lohnt sich meiner Erfahrung nach.

Ein normaler Zurgriff auf eine statless Session Bean liegt ca. bei einer zehntel Sekunde. D.h. EJB kann sehr wohl performant sein - wie Herrmann Schmitt richtig bemerkt hat. <br> Der Rest ist oft eine Frage des Designs. <br> <br>
Holger Schulz: Sorry, dass ich mich nicht gemeldet habe, hatte schon ewig nicht mehr die Zeit mich hier aus zu lassen ;-) <br>
Wenn es noch aktuell ist: [email protected] <br><br>

Ciao, Andreas Ullman