PDA

View Full Version : ODBC-Performance



KM
28-06-06, 15:23
Hallo,

auf unser System wird teilweise mittels ODBC zugegriffen. Für diese ODBC-Zugriffe sind schnelle Antwortzeiten erforderlich.

Ich habe jetzt schon folgendes eingestellt:

- für das Subsystem QUSRWRK einen eigenen Pool eingerichtet
- die QZDASOINIT-Jobs diesem Pool zugeordnet
- in der Klasse QPWFSERVER die Ausführungsprio auf 10 und die Timeslice auf 5000 eingestellt

Trotzdem sind die Antwortzeiten zum Teil zu langsam. Was könnte ich noch einstellen, um das Ganze zu forcieren ?

Gruß,
KM

Fuerchau
28-06-06, 15:45
Eigentlich gilt für dich das Gleiche, was auch dort schon gesagt wurde:
http://www.rlpforen.de/showthread.php?t=9961

KM
28-06-06, 15:57
Das Problem ist einfach, dass die Antwortzeiten in vielen Fällen "normal" sind, also bei unserer Applikation ca. eine halbe Sekunde betragen. Aber teilweise muß man auch 4 oder 5 Sekunden warten, ohne dass jetzt groß was anderes auf der Maschine läuft. Ich dachte erst es könnte am Erstellen eines weiteren QZDASOINIT-Jobs liegen. Aber das ist es nicht. Wie können also diese unterschiedlichen Antwortzeiten sonst noch zustandekommen ?

Gruß,
KM

Fuerchau
28-06-06, 16:43
Ist die Abfrage denn immer identisch ?
Schalte mal in der ODBC-Konfig den Debug-Modus ein und schau nach, was dann im Joblog des Langläufers steht.

Es kann nur an fehlenden Indizees liegen oder an mangelhaften SQL-Optimierungen (ähm -Befehlen).

BenderD
30-06-06, 09:07
Hallo,

STRDBMON für alle (wichtig!!) Jobs, detailliert auswählen, am besten von Green Screen (Oops Nerv hängt sich bei vielen Jobs gerne auf). Anschließend aus den Daten per SQL alles rauslöschen was nicht Job QZDASOINIT hat und dann detaillierte Analyse per Ooops Nerv auf Statement Ebene nach Zeitt descending sortiert und die Zeitfresser untersuchen.
Parallel dazu Kontroll Messung/Beobachtung CPU und Plattenauslastung; je nach Gusto mit Management Central (für die Mausschieber Fraktion) oder per WRKDSKSTS/WRKSYSSTS/WRKACTJOB (für die Senioren und Puristen unter uns).

mfg

Dieter Bender

PS: Wer lieber zaubern lässt, kauft sich einen entsprechenden Kasten und macht es dann damit.


Das Problem ist einfach, dass die Antwortzeiten in vielen Fällen "normal" sind, also bei unserer Applikation ca. eine halbe Sekunde betragen. Aber teilweise muß man auch 4 oder 5 Sekunden warten, ohne dass jetzt groß was anderes auf der Maschine läuft. Ich dachte erst es könnte am Erstellen eines weiteren QZDASOINIT-Jobs liegen. Aber das ist es nicht. Wie können also diese unterschiedlichen Antwortzeiten sonst noch zustandekommen ?

Gruß,
KM

KM
05-07-06, 06:59
Hallo,

wir haben jetzt unsere Programme nochmal optimiert (z.B. Dateien offen lassen und Programme mit RETURN beenden, etc.). Damit wurden die Antwortzeiten schon mal deutlich besser. Ein Debug, Trace bzw. STRDBMON hat keine neuen Erkenntnisse gebracht. Evtl. war der Pool auch zu klein gewählt. Denn wenn viele Benutzer gleichzeitig arbeiteten, war die Performance extrem schlecht. Ich habe den Pool jetzt wieder gelöscht und lasse die QZDASOINIT-Jobs wieder in *BASE laufen. Aufgefallen ist uns auch, dass die größten Wartezeiten beim ODBC-Verbindungsaufbau waren. Wir haben das jetzt von odbc_connect auf db2_connect (bezieht sich alles auf PHP) geändert und sind der Meinung, dass das auch deutlich schneller ist. Kennt evtl. jemand die Unterschiede dieser beiden connects ? Oder kennt jemand noch andere Zugriffsmethoden von PHP zur iSeries-Datenbank ? Oder gibt es Kommunikationsmöglichkeiten über Dataqueue o.ä. ?

Gruß,
KM