Hallo,

das ist der Kern der ganzen Debatte!
First do it right, then make it fast. Den ersten Entwurf sauber strukturieren, jede Teilfunktionalität zentralisieren und ohne große Rücksicht auf Performance implementieren. Dann die Stellen ermitteln (durch messen!!! Log4J ist dein Freund), wo die Zeit verbraucht wird und diese optimieren (wieder messen!!!). Für den Serverteil kann man bei stored Procedures den Database Monitor verwenden.
Beim Vergleich der beiden Varianten (stored Procedures und DTAQ) ist noch zu breücksichtigen:
- JDBC ist deutlich ausgereifter als das Toolbox Spielzeug (DTAQs)
- JDBC Connections kann man einfach poolen
- ein zentraler DTAQ Server Job ist ein Flasschenhals, da RPG nicht Multithreading kann
- multiple DTAQ Server sind (fast) immer wackeliger als die QZDASOINIT Jobs
Zu Baldurs Argumenten würde ich noch ergänzen:
- Wartezeiten auf Ressourcen und Ressourcen Engpässe sind der primäre Flaschenhals
- Lock Konflikte gehören zu den beliebtesten Fehlern, mit beliebigen Wartezeiten und/oder Fehlfunktionen
- bei eigenen Serverjobs ist das warten auf abgeschmierte Server auch sehr beliebt.
- bei der Java RPG Variante sind die synchronen Übergänge zwischen RPG und Java am übelsten; also:
- Aufruf von Java aus RPG mit Start einer JVM pro Job
- Aufruf von RPG aus Java mittels JNI
Mein Resumee:
- am besten wäre das komplett in Java zu machen.
- das beste vom zweitbesten sind stored Procedures
- DTAQs trotten mit Abstand dahinter
- mit RPG Java Mix fliegt man entweder sofort raus, oder hat eine Lebensstellung.

mfg

Dieter Bender

PS: Zu dieser Problematik gibt es auch ein paar Hinweise in meiner Java auf AS400 FAQ auf meiner Webseite.



Zitat Zitat von Fuerchau
Aber: Diese ganze Diskussion ist fast nicht relevant.
Ich habe bereits mehrere 1000 Call's pro Sekunde in einem Batchjob gesehen, bei gleichzeitig ca. 1500 weiteren parallelen Job's.

Viel Problematischer sind da eher falsche SQL's (Zugriffspfade, Tablescan's) sowie das Netzwerk bei Remote-Zugriffen.
Was bringt mir da eine Optimierung der CALL's um Microsekunden, wenn der Netztransfer Sekunden oder der SQL Minuten benötigt.