Im Allgemeinen sollen potentielle Engpässe früh erkannt und Entwick-
lungskosten reduziert werden.
Die Aufgaben und die Ziele performancesichernder Maßnahmen variie-
ren je nach Projektfortschritt. Im Folgenden sind einige Punkte darge-
stellt.
• Während der Designphase
⇒ Vergleichsmessungen zur Ermittlung der optimalen Architektur- /
Implementierungsvarianten,
⇒ Bestimmung des zu erwartenden Lastmodells als Grundlage für
Entscheidungen.
• Vor der Produktionseinführung
⇒ Bestimmung des später zu erwartenden Antwortzeitverhaltens,
⇒ Bestimmung des mit dem gegebenen Umfeld realisierbaren
Transaktionsdurchsatzes,
⇒ Lasttest zum ultimativen Nachweis der Erfüllung der Performan-
cevorgaben.
• Nach der Produktionseinführung
⇒ Verbesserung des realen Antwortzeitverhaltens,
⇒ Vorbeugen von Problemen aus dem Anwachsen des Datenbe-
standes.
Basis einer Performanceuntersuchung müssen immer quantifizierbare
Ziele sein. Schwammige Anforderungen, wie z.B.: „Datenbank optimal
aufsetzen“ „CPU-Zeit sparen“ sind wenig hilfreich.
CPU, I/O oder Speicher sparen
Es fehlt die Quantität. Wann ist dieses Ziel je erreicht? Irgendwo fin-
det sich immer eine Verbesserungsmöglichkeit. Aber wie steht es mit
Aufwand / Nutzen?
„Datenbank optimal aufsetzen“
Es gibt keine optimale Datenbank oder optimale Applikation. Das
“Optimum” ist immer an eine konkrete Umgebung und an die Bedürf-
nisse des Anwenders gebunden
Wichtig ist das Setzen von Tuningzielen der Art:
⇒ Wir müssen 500 Buchungen je Minute schaffen.
⇒ Zum Monatsende müssen je Stunde 100.000 Rechnungen erstellt
werden.
⇒ Die Instanz muss 5 Reports parallel verarbeiten können.
⇒ Der Programmzweig „Buchen Zahlungseingang / -ausgang“ darf bei
Volllast (100 Transaktionen / Sekunde) maximal 50 % der Anlagen-
CPU binden.
Auf derartige Ziele lässt sich zielstrebig hinarbeiten. Nach dem Errei-
chen des quantifizierten Ziels kann die Entwicklerkapazität an anderer
Stelle eingesetzt werden.
Keine Kommentare:
Kommentar veröffentlichen