Wenn dies Ihr erster Besuch hier ist,
lesen Sie bitte zuerst die Hilfe - Häufig gestellte Fragen
durch. Sie müssen sich vermutlich registrieren,
bevor Sie Beiträge verfassen können. Klicken Sie oben auf 'Registrieren', um den Registrierungsprozess zu
starten. Sie können auch jetzt schon Beiträge lesen. Suchen Sie sich einfach das Forum aus, das Sie am meisten
interessiert.
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.
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
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.
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
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
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>
Comment