Performance von Entity Bean create vs. JDBC insert

[ichbindiegute]

Hallo!

Ich schreibe gerade an meiner Diplomarbeit zum Thema Reengineering einer Java Bibliothek und Portierung dieser in eine J2EE Umgebung mit EJB.

Ich benutze
Application Server: JBoss 4.0.2
Datenbank: ORACLE 10xe
EJB 2.0

Meine Frage bezieht sich auf Performance:
Es werden 160 Datensätze in eine Datenbanktabelle eingetragen. Die Programmlogik erzeugt ungefähr 400 JDBC insert statements, die natürlich zu ungefähr 240 SQL Errors führen wegen DUPLICATE KEYS. Dies ist aber kein Problem.

In der neuen Version benutze ich Entity Beans, um genau dieselben Daten in die Datenbank einzutragen. Auch hier kommt es natürlich zu ungefähr 240 CreateExceptions.

Meine Frage: Wie kann es sein, dass die JDBC Aufrufe insgesamt etwa 150% mehr Zeit beanspruchen, als die Entity Bean create Aufrufe? Wie kann der Application Server die Performance so stark erhöhen?

Ich bin dankbar für jeden Hinweis!

Viele Grüße,
Monika

[Alwin Ibba]

Hallo Monika,

Läßt sich pauschal schwer beantworten. Es gibt unzählige Einstellungen die die Performance beeinflussen. Ich würde darauf tippen, das die Entity Beans sich bereits im Cache befinden. Dann weiß der JBoss das z.b. ein key bereits existiert ohne einen insert auf die Datenbank zu machen. Das hängt aber von der commit option (defaultmäßig commit option B) ab und ob Du alle Entity Beans in einer einzigen Transaktion erzeugst.

Zudem stellt sich die Frage wie optimiert das handgestrickte JDBC ist. Wird jeder insert einzeln commited? Werden batch inserts benutzt? Werden PreparedStatement-Objekte wiederverwendet etc.

Das mit den 240 duplicate keys verstehe ich nicht ganz. Was macht das für einen Sinn in einer Testumgebung? Die Fehler/Ausnahmebehandlung beeinflusst die Performance ja nochmal und realistische Bedingungen sind das nicht gerade.

Wie dem auch sei, Kapitel 11 des "JBoss Application Server Guide" erklärt JBoss Entity Beans im Detail und erläutert auch, wie man das CMP logging einschaltet, so das Du sehen kannst, was der JBoss nun wirklich an die DB sendet.

http://labs.jboss.com/jbossas/docs

Viele Grüße,

Alwin

[ichbindiegute]

Ich würde darauf tippen, das die Entity Beans sich bereits im Cache befinden. Dann weiß der JBoss das z.b. ein key bereits existiert ohne einen insert auf die Datenbank zu machen.

Diese Lösung fand ich prima. Vor allem habe ich in einem anderen Forum eine übereinstimmende Antwort bekommen:

Das liegt daran, daß der AS die Entities cached. Es wird eine CreateException geschmissen, ohne erst in der DB den Key zu prüfen, da der AS dank caching bereits weiß, daß dieser bereits existiert.

Aber ich kann durch die DEBUG Log Meldungen des AS sehen, dass er wirklich jedesmal ein INSERT Statement an die Datenbank schickt. :-(

Zudem stellt sich die Frage wie optimiert das handgestrickte JDBC ist. Wird jeder insert einzeln commited? Werden batch inserts benutzt? Werden PreparedStatement-Objekte wiederverwendet etc.

Das INSERT Statement im alten Modul ist der Bottleneck. Vermutlich ist nicht der AS unheimlich schnell, sondern das JDBC PreparedStatement unheimlich langsam.

Das mit den 240 duplicate keys verstehe ich nicht ganz. Was macht das für einen Sinn in einer Testumgebung? Die Fehler/Ausnahmebehandlung beeinflusst die Performance ja nochmal und realistische Bedingungen sind das nicht gerade.

Die 240 duplicate keys entstehen durch die Programmlogik. Es geht um ein Produktivsystem, in dem die durch EJB ersetzten Module nur noch durchschnittlich 40% der ursprünglichen Laufzeit benötigten. Es geht also gar nicht um eine realistische Testumgebung, sondern um ein Produktivsystem.

Noch weitere Vorschläge?

Viele Grüße,
Monika

[Alwin Ibba]

Ok, verstehe.

Vermutlich wird es an der Programmlogik liegen.

Der JBoss benutzt ja intern auch PreparedStatements und kann auch nur Standard-Optimierungen verwenden. Vielleicht ist das handgestrickte JDBC nicht optimal programmiert bezüglich dieser Optimierungen. Mir fallen da momentan nur drei Sachen ein:

• Wird für jedes insert ein neues PreparedStatement-Objekt erzeugt oder wird ein PreparedStatement erzeugt und wiederverwendet?
• Ist auto-commit eingeschaltet oder werden alle/einige inserts in einer Transaktion zusammengefaßt und gemeinsam commited? Wie wird das in der EJB-Version gehandhabt? Eine JTA-Transaktion für alle creates?
• Werden JDBC batch inserts benutzt? Das wird aber der JBoss wohl auch nicht tun, also wird es daran nicht liegen.

Viele Grüße,

Alwin