Dipl-Math. Norbert Hattrup ist Geschäftsstellenleiter der Internationalen Consulting und Rechenzentrum GmbH (ICR), München.

Versetzt man sich in die Lage eines Anwenders, also des Benutzers einer Datenverarbeitungsanlage und nicht des Betreibers, so erfährt die Frage, was denn eine gute Performance sei, völlig neue Aspekte. Norbert Hattrup geht das Thema einmal von dieser Seite an.

Ein RZ-Betreiber oder seine Beauftragten (in der Regel Systemprogrammierer, wenn es um Performancefragen geht) greifen aus der Vielzahl leistungsbeschreibender Größen zur ständigen Beobachtung einige signifikante heraus, beispielsweise CPU-Belastung, TSO-Short-Response-Time oder die Pagingrate. Diese werden im laufenden Betrieb von den Realtime-Monitoren gemessen und über die Online-Komponente am Bildschirm angezeigt.

Derartige Software-Monitore gibt es für alle Subsysteme oder Transaktionsmonitore, zumindest in der IBM-Welt, also für MVS, IMS, CICS, DB2 etc., und jeder Monitor berichtet über seine eigenen, systembezogenen Leistungsindikatoren von der MVS-, IMS-, CICS- und DB2-Performance. Doch was hilft es dem Anwender vor seinem Terminal mit zu langen Antwortzeiten, wenn der Systemprogrammierer zu Recht behauptet, sein CICS sei optimal getunt?

Was hier fehlt, ist eine Integration der Performancedaten zu einer Anwenderperformance. Nur - was ist das? Verwendet man einen anderen Begriff, nämlich Servicegrad, so klingt die Forderung gar nicht mehr so fremd und ungewöhnlich. Servicegrad im Gegensatz zu Performance ist also anwender- beziehungsweise anwendungsbezogen statt systemimmanent. Performance-Überwachung aus Anwendersicht ist demnach nichts anderes als Servicegrad-Kontrolle. Doch bevor ein Servicegrad kontrolliert werden kann, muß er erst definiert und vereinbart werden.

Servicegrad-Definition

Zentrale Einflußgrößen für den Servicegrad sind:

- Endbenutzer-Antwortzeit: Zeitintervall zwischen der Eingabe des letzten Zeichens einer Nachricht und der Ausgabe des ersten Zeichens der Antwort des Systems am Terminal. Die Zeit bis zur Ausgabe des letzten Zeichens wird auch häufig Anlieferungszeit genannt.

- Verfügbarkeit (VB): Mittlere Zeit zwischen Ausfällen (MTBF) dividiert durch die Summe aus mittlerer Reaktionszeit (MTTC), mittlerer Reparaturdauer (MTTR) und mittlerer Zeit zwischen Ausfällen. Diese Definition ist für sämtliche Ressourcen gültig.

VB = MTBF

(MTTC + MTTR + MTBF)

- Termintreue (TT): Anzahl der Terminüberschreitungen (TÜ) bezogen auf die Gesamtzahl der Aufträge (GA) in einer Zeiteinheit.

TT= GA -TÜ

GA

Natürlich gibt es noch weit mehr Parameter zur Bestimmung eines Servicegrads. Welche von den servicebestimmenden Größen zur Vereinbarung und Berichterstattung ausgewählt werden, hängt von den individuellen Anforderungen einer Installation ab.

Servicegrad-Vereinbarung

Servicegrad-Vereinbarungen als Grundlage des EDV-Betriebs ist die Festlegung von Qualitätsanforderungen für angebotene oder geforderte Dienstleistungen. Dabei sollten die Vereinbarungen mindestens die folgenden Informationen enthalten:

- Identifikation der vereinbarenden Personen oder Gruppen,

- Beschreibung der Workload und ihrer Betriebszeiten,

- Servicegrade mindestens für die oben vorgestellten Größen,

- Gültigkeitsdauer.

Servicegrad-Kontrolle

Individuell definierte Servicegrade werden, zumal dann, wenn sie anwendungsorientiert sind, von keinem auf dem Markt angebotenen Standardtool, sei es ein Hardware- oder Softwaremonitor, als Berichtsobjekte behandelt. Trotzdem sind sie unverzichtbarer Bestandteil einer Methodik, die die aktuelle Kontrolle des Servicegrades zum Ziel hat.

Die Antwortzeit läßt sich in sehr viele Komponenten zerlegen. Aufgrund dieser relativen Unüberschaubarkeit muß schon bei der Vereinbarung Wert auf die praktische Überprüfbarkeit gelegt werden. Deswegen sollte nicht, wie vermutlich der Endbenutzer fordert, die Anlieferungszeit, sondern die Endbenutzer-Antwortzeit zur Vereinbarung hergenommen werden. Denn die DV-Zentrale beziehungsweise das Rechenzentrum kann keine Verantwortung für einen remote erfolgenden Bildaufbau übernehmen, es sei denn, es liegt ein systematischer, das heißt Konfigurationsfehler vor.

Trotzdem bleibt die ständige Überprüfung der Antwortzeit ein ernsthaftes Problem, gibt es doch so gut wie keine Standardwerkzeuge die sowohl die Systemantwortzeit als auch die Netzlaufzeit anwendungsbezogen messen. Der eine Teil, die Systemantwortzeit, ist im schlechtesten Fall nachträglich über selbstgeschriebene Log-Auswerteprogramme erhältlich, die Netzlaufzeit jedoch ist in dieser Form nicht zu ermitteln.

Behelfen kann man sich hier auf mehrere Weisen. So werden zu bestimmten, vorher festgelegten Zeiten, Standardtransaktionen, deren Zeichenumfang und minimale Antwortzeit bekannt sind, abgeschickt und gemessen. Dieser dann ermittelte Erhöhungsfaktor bezogen auf die minimale Netzlaufzeit wird dann den Transaktionsantwortzeiten zugeschlagen.

Dies setzt natürlich voraus, daß der Umfang der übers Netz transferierten Nachrichten bekannt ist und die Verhältnisse im Netz stabil sind, also insbesondere keine Wartezeiten durch Behinderung auftreten. Durch einen Wechsel der Periodizität läßt sich allerdings auch hier allmählich ein Zeitprofil von der Leistungsfähigkeit des Netzes ermitteln, das man zur Bestimmung der Netzlaufzeit in die Berechnung miteinbezieht.

Die Berechnung der Endbenutzer-Verfügbarkeit ist ein ähnlich gelagertes Problem wie das der Endbenutzer-Antwortzeit. Auch hier ist der Anwender in Ermangelung entsprechender Werkzeuge auf eigene Berechnungsgrundlagen und Meßwertverknüpfungen angewiesen. In jedem Fall muß die Basis eine Ausfallstatistik sein, in der alle Hardware- und Softwareausfälle protokolliert wurden.

Die Auswertungen solcher Statistiken erfolgt jedoch in der Regel produkt- oder komponentenweise und nicht systemweit. In den seltensten Fällen findet eine Verknüpfung von Ausfallstatistiken statt, um Endbenutzer-Verfügbarkeiten zu ermitteln. Notwendig dazu wäre eine Umrechnung sämtlicher Ausfälle innerhalb eines Kommunikationsnetzes unter Zuhilfenahme einer Netztopologie-Datenbank auf die betroffenen Endgeräte.

Neben der aktuellen Servicegrad-Kontrolle ist aber auch eine prophylaktische Ermittlung signifikantes Performance-Indikatoren wesentlich. Denn hier ist schon im Vorfeld zu analysieren, welche Komponenten einer Datenverarbeitungsanlage später einen Engpaß darstellen werden und die vereinbarten Servicegrade auf bloße Absichtserklärungen reduziert.

Die Hilfsmittel für eine derartige prophylaktische Engpaßanalyse sind seit langem bekannt und auch verfügbar. Leider ist ihre Akzeptanz nur auf wenige Installationen in der Bundesrepublik beschränkt. Es handelt sich dabei um die analytischen Modelle der angewandten Warteschlangentheorie, die für das IBM-Umfeld auch als Softwarepakete erhältlich sind und die eine Analyse potentieller Engpässe wesentlich erleichtern. Für die Modellbildung werden Größen wie Ankunftsrate, Multiprogramminggrad und Servicezeit verwendet, eben Größen, wie sie auch von den spezialisierten Performancemonitoren geliefert werden. Dabei unterscheidet man drei Phasen.

In der Entwurfsphase werden aus den aktuellen Meßdaten Gleichungen erstellt, die ein Abbild des realen Systems in bezug auf die Leistungsfähigkeit des Gesamtsystems darstellen. In der Validierungsphase werden die errechneten Werte für denselben Meßzeitraum mit dem am realen System gemessenen verglichen. Falls Abweichungen festzustellen sind wird das Modell kalibriert. Die Güte eines solchen Modells ist daran abzulesen, wie wenig gemessene von den errechneten Werten abweichen. Abweichungen von mehr als 10 Prozent sollten nicht toleriert werden.

In der eigentlichen Vorhersagephase kann das Leistungsverhalten des Systems mit einem gültigen Modell unter veränderten Konfigurationsbedingungen modelliert werden. Als sogenannte "What if"-questions sind sowohl veränderte Hardware-Kenndaten als auch Ankunftsraten von Transaktionen formulierbar. Das Modell errechnet daraus für die Praxis sehr wichtige Performance-Indikatoren, nämlich Antwortzeiten und die Belastungen der Komponenten des betrachteten Systems wie CPU, Hauptspeicher, Kanäle, Platteneinheiten etc.