JDBC SQL Performabce

[Nili]

Hi!

Habs von einem PC laufen lassen. Verwendet JTOpen 4.8 mit Java 1.5.
JTOpen bekommst Du unter https://sourceforge.net/projects/jt400. Aus dem Zip-File brauchst Du nur jt400.jar.

[Nili]

Moin!

Hab mir mal den Spass gemacht und es auf der i5 laufen lassen.
Lief mit Java 1.4.2 und JTOpen 4.8. Zusätzlich hab
ich den LogWriter deaktiviert, sonst war es unerträglich.

Ergebnis i5:

Erstlauf war ne Katastrophe hat 3 Minuten gedauert.
Danach hat es sich eingependelt auf ca. 6 Sekunden (auch auf verschiedenen QShell-Sitzungen).

Starte: Tue Sep 06 10:13:05 UTC 2005
JDBC init: Tue Sep 06 10:13:08 UTC 2005
Create Table: Tue Sep 06 10:13:08 UTC 2005
Insert 10.000: Tue Sep 06 10:13:11 UTC 2005
Close: Tue Sep 06 10:13:11 UTC 2005

i5 mit jt400Native.jar:

Erstlauf wieder schlecht mit 33 Sekunden danach gings:

Starte: Tue Sep 06 10:24:55 UTC 2005
JDBC init: Tue Sep 06 10:24:57 UTC 2005
Create Table: Tue Sep 06 10:24:58 UTC 2005
Insert 10.000: Tue Sep 06 10:25:01 UTC 2005
Close: Tue Sep 06 10:25:01 UTC 2005

Irgendwie kein grosser Unterschied???

P.S. Nur so nebenbei, wenn ich den LogWriter auch auf PC rausnehme komme ich auf ne Zeit von ca. 1-2 Sekunden immer.

[pwrdwnsys]

@Nili,

dann versuchs doch mal mit einen CRTJVAPGM OPTIMIZE(40) Dann rennen die Programme normalerweise wie der Teufel. Außerdem : Wenn Du Dich "normal" identifiziert hast, gehst Du aus der AS400 raus und wieder rein. Das kannst Du umgehen, indem Du als Adresse LOCALHOST und als Benutzer / kennwort *CURRENT *CURRENT verwendest. Aber kann ja sein das weißt Du alles schon
Zudem dauert das Laden der qsh ja schon einige Zeit. Wenn Du also mit RUNJVA arbeitest, musst Du die Vorlaufzeit abziehen.

[Nili]

Hi!

Ne, ne hab immer die reine Laufzeit des Connect, Insert, Close gemeint. Inder Qshell hab ich mich schon befunden. Wenn Du auf die Timestamps schaust siehst Du ja, dass der reine Insert nur ca. 3 Sekunden dauert. Auf optimieren hatte ich keine Lust und Zeit mehr.

Ist Dein Ergebnis mit JTOpen 4.8 nun besser geworden?

[BenderD]

Hallo,

nchdem ja schon einiges in den Antworten drin ist, noch ein paar Aspekte:
- addBatch ist nicht von allen Treibern gleich implementiert, da gibt es durchaus Dummies ohne jeden Effekt, darunter zumindest die älteren Versionen der Toolbox.
- addBatch ist Programm technisch komplexer (welche 3 von den 100 haben nun eigentlich nicht geklappt und warum) und von daher eher zu unterlassen.
- inserts brauchen keinen ODP
- für die Java Geschwindigkeit ist die Prozessorspeed ausschlaggebend; je nach AS400 und PC sind da Faktoren bis zu 5 völlig normal. Die Geschwindigkeit ist nur für neueste Prozessoren als vergleichbar zu erwarten, schneller ist die AS400 auch da nicht, wenn ich neueste Intel dagegen vergleiche.
- COBOL/RPG ist in dieser Art eins zu eins Benchmarks immer schneller - für wirkliche Leistungsvergleiche muss man reale Anwendungen nehmen, die alle Möglichkeiten ihrer jeweiligen Umgebung nutzen. Java nutzt dann Multithreading beim schreiben und extensives caching beim lesen, dann sieht der Vergleich völlig anders aus. Den Amazon Webshop oder die Ebay Anwendung könnte man in RPG oder COBOL nicht schreiben, das wäre zu langsam.
- es gibt nichts geschenkt auf der Welt: moderne Technologien brauchen in der EDV adäquate Hardware

Ein paar Aspekte sind auch in meiner Java-AS400 FAQ auf meinen Webseiten erläutert.

mfg

Dieter Bender

Hallo Forum,

nachdem ich hier schon im Forum nach dem Problem gesucht habe und immer noch nicht fündig geworden bin, hier meine Bitte um Hilfe. Das Problem ist die performance beim schreibenden JDBC Zugriff. Ich erstelle mir eine Tabelle mit

CREATE TABLE SQLTEST (FLD1 CHAR (10 ) NOT NULL WITH
DEFAULT, FLD2 CHAR (10 ) NOT NULL WITH DEFAULT)

Wenn ich jetzt mit SQL COBOL 10.000 Sätze in die Tabelle einfüge, dauert das ca. 1s. Auszug :

PERFORM WITH TEST AFTER UNTIL V-ZAEHLER > 10000
EXEC SQL
INSERT INTO SQLTEST
VALUES ("FLDA", "FLDB")
END-EXEC
ADD 1 TO V-ZAEHLER
END-PERFORM.

Mache ich dasselbe mit einem JAVA-programm, dauert das ganze 19s. Ohne Verwendung von ProparedStatements noch länger. Der Sourcecode sieht so aus :

int j = 0;
try {
PreparedStatement ps = AS400.prepareStatement("INSERT INTO sqltest VALUES(?, ?)");

for (int i = 0;i<10000;i++) {
ps.setString(1, "FLDA");
ps.setString(2, "FLDB");
ps.addBatch();
j++;
if (j==1000) {
ps.executeBatch();
j=0;
}
}
} catch (Exception ex) {
ex.printStackTrace();

}

Was läuft hier verkehrt ? Habe das Gefühl das bei jedem executBatch schon auf die Tabelle der iSeries zugegriffen und ein ODP erstellt wird. Allerdings ist die Maschine während des ganzen Vorganges nicht ausgelastet. CPU <10%, kein Paging, nichts. Version 5.2 ist im Einsatz auf einer 810. Das Problem triff aber genau so auf einer 870 mit 5.3 und einer 170 mit 5.2 auf.
Bin ratlos und für jeden Tip dankbar.

[pwrdwnsys]

So, nachdem heute ausführliche Tests der gesamten Anwendung mit JTOpen 4.8 gelaufen sind, hier das Feedback : Die Anwendung rennt damit wie nie zuvor !. Ein weiteres Problem in der (Web)Anwendung war der ConnectionPool. Hier wurden verschiedene Implementierungen ausprobiert, letztendlich hat sich die BEA-Implementierung des Connection Poolings in Zusammenarbeit mit dem JTOpen Treiber als die performancegünstiges Lösung herausgestellt. Mit anderen Treibern konnten 2 unterschiedliche Effekte beobachtet werden :


a) Innerhalb des QZDASOINIT Jobs wurde seltsamerweise die Datei nach jedem executeBatch() Statement neu geöffent, wobei der vorhandene ODP beibehalten wurde. das führte dazu, das bei einer Datei mit 300.000 Datensätzen die Datei letztendlich 300 mal in den offenen Dateien aufgeführt wurde ! Damit paget die Maschine natürlich wie verrückt und die Performance geht in die Knie

b) Gleiches Zugriffsschema, nur andere Datei (Unterschiede im Ablauf nicht feststellbar) Ab einer unbestimmten Anzahl von Datensätzen wird die Datei für JEDES Insert-Statement die Datei geöffnet, der Datensatz hinzugefügt und die Datei wieder geschlossen. Das dies nicht besonders schnell ist brauche ich wohl nicht zu erläutern.

Danke an alle die mir geholfen haben
Gruß Karsten