Tuningfall 1:

 

DB2- und AP-Tuning mit dem Ziel der Kostensenkung im Accounting (MIPS)

Im folgenden Tuningfall wurde ein System, das auf CICS-Transaktionen basiert, untersucht. Sie werden immer dann angestoßen, wenn bestimmte "event"-Punkte im Produktionsprozeß erreicht sind.

Dies geschieht zwischen ca. 12.000 und 16.000 mal pro Tag und im Maximum - die zukünftige Planung berücksichtigt - ca. 2,4 Millionen mal im Jahr.

Die maximale Dauer einer Transaktion darf so, ohne Berücksichtigung von Rüstzeiten und notwendigen „Pufferzonen" bei einer Verfügbarkeit von ca. 60% an einem Produktionstag, 2 Sekunden betragen. Diese Rahmenbedingung konnte bereits in einem ersten Tuningschritt erfüllt werden.

Dennoch blieb die CPU-Zeit pro Transaktion mit ca. 0,2 Sekunden (200 ms) im Durchschnitt zu hoch und damit zu teuer.

Als Hauptgrund der hohen Accountingkosten pro Monat bei der Berechnung des Verbrauchs nach MIPS-Stunden waren genau diese CPU-Aufwände zu bezeichnen. Diese Kosten galt es in den folgenden Vorgehensschritten signifikant zu senken:

  1. Analyse des Applikationssystems
  2. Erarbeiten und Planung der Lösungsmaßnahmen
  3. Test und Implementieren der Lösungen
  4. Vergleich der Ergebnisse und weitere Maßnahmen

Im Schritt 1 kristallisierten sich 5 Programme / Module heraus, die zusammen zwischen 80% und 90% des kritischen Zeitverbrauchs (CPU und „elapsed“) verursachten. Die Lösung sollte eine Beschleunigung der Programmabläufe durch folgende Maßnahmen sein:

  1. Senken der DB2-Zeiten durch Umschreiben der Queries in den betroffenen Programmen

  2. Unterstützung der „neuen“ Query-Formulierungen über zusätzliche Indizes und Neuorganisation häufig benutzter Datenbereiche

  3. Minimieren von Zugriffshäufigkeiten zum Zählen, Plausibilisieren usw.

Zunächst wurde in den mit Priorität 1 versehenen 3 Programmen, die die Hauptlast an CPU-Zeit verursachten, eine Reduktion des CPU-Verbrauchs von mehr als 300 ms auf ca. 3,5 ms erreicht.

Damit wurde eine Senkung der Accountingkosten von € 90.000 im Dezember, auf € 55.000 im Januar und auf € 19.000 im Februar, März und in den folgenden Monaten auf 38.000 € erreicht.

Die durchschnittlichen MIPS-Kosten / Transaktion waren dabei stabil.

Insgesamt bedeutete dies die Senkung der Accountingkosten - hochgerechnet auf die Jahre 2004 / 2005 und folgende – auf einen Wert von ca. € 456.000, anstatt wie bisher € 1.080.000. Damit wurden diese Kosten auf weniger als 42 % des Ausgangswertes reduziert – trotz steigender CICXS-Transaktionszahlen durch mehr produzierte Produkte.

Die Analyse brachte noch weitere Tuningpotentiale in anderen Programmen / Modulen zu Tage. Sie lagen jedoch mehr im „elapsed time“ Verbrauch der Module und schlugen so nicht direkt auf die Accountingkosten von VP-65 durch.

Dennoch bringt ihre Implementierung Vorteile in „wait“- und Antwortzeiten des gesamten Applikationskomplexes.

Der Aufwand für diese Maßnahmen betrug insgesamt ca. 3,5 Mannmonate und wurde ausschließlich von der Firma S.K. Consulting Services GmbH geleistet.


 

Tuningfall 2:

DB2- und AP-Tuning zur Kostensenkung auf DB2(MIPS)

Im folgenden Tuningfall wurde ein System, das rein auf dynamischen DB2 Zugriffen basiert, untersucht. Die Zugriffshäufigkeit pro Tag liegt bei ca. 8 Mio bis 10 Mio Zugriffen pro Tag. Nicht nur, dass damit das zentrale DB2-System stark belastet wurde, es gab ein Reihe von Faktoren, die das System aufwendig und teuer werden liessen.

Die damit verbundenen hohen Accountingkosten pro Monat bei der Berechnung des Verbrauchs nach MIPS-Stunden galt es in den folgenden Vorgehensschritten signifikant zu senken:

1. Analyse des Applikationssystems

2. Erarbeiten und Planung der Lösungsmaßnahmen

3. Test und Implementieren der Lösungen

4. Vergleich der End-Ergebnisse und weitere Maßnahmen

Im Schritt 1 kristallisierten sich bestimmte Aktionen, die vom BEA-Server und dem genutzten System TOPLink automatisch ausgelöst wurden heraus, die zusammen zwischen 40% und 50% des kritischen Zeitverbrauchs (CPU und „elapsed“) verursachten. Zudem waren einige ineffiziente Query-Formulierungen und häufige Zugriffe auf statische "Stammdaten" an dem Desaster schuld. Die Lösung sollte eine Beschleunigung und Minimierung der Zugriffe durch folgende Maßnahmen sein:

1. Eliminieren unnötiger Zugriffe auf das zentrale DB2:

a. Die Anzahl der Abfragen zur Bestätigung von existiereneden Connects wurde halbiert.

b. Die Zugriffe auf die "Stammdaten" wurden auf dem Server "gecached"

c. TOPLink wurde entfernt

d. Die dynamischen Queries wurden mit Parametermarkern formuliertund

e. Das "dynamic cacheing" auf dem zOS-Rechner eingeschaltet.

2. Vermeiden unnötiger COMMITs (auch beim Lesen), die von BEA und/oder TOPLink ausgelöst worden waren

3. Senken der DB2-Zeiten durch Umschreiben der kritischen Queries

4. Unterstützung der Query -Formulierungen über zusätzliche Indizes

5. Unterstützung kritischer Modifikationen durch 21 "stored prodcedures" anstatt dynamischer SQLs

Durch die gebündelten Massnahmen in Okt. 1 bis Pkt. 4 wurden nach Einsatz der Änderungen im September die CPU-Kosten von ca. 50 - 60 T€ auf 12 – 16 T€ in den Monaten Oktober bis Dezember gesenkt. Das bedeutet eine Senkung der CPU-Kosten um ca. 80% !

Die Analyse brachte noch weitere Tuningpotentiale / Defects zu Tage. Sie werden sich weiter auf die CPU-Zeiten und auch auf die „elapsed time“ niederschlagen. Sie bringen auf jeden Fall noch Vorteile in „wait“- und Antwortzeiten des gesamten Applikationskomplexes.

Dies ist notwendig, da die Anwendung erst 30% ihrer geplanten Last auszuhalten hat. Weitere 70% sind in den Jahren 2005 und 2006 geplant.

Der Aufwand für diese Maßnahmen betrug insgesamt ca. 6 Mannmonate ( ca. 70.000 € ) und wurde von der Firma S.K. Consulting Services GmbH zusammen mit dem Entwicklungsteam des AGgeleistet.