Mit neuer DIN-Norm laßt sich die DV-Leistung messen

10.04.1992

Planung, Messung und Überwachung der, DV-Kapazität sind ein Teilbereich des Technologie-Managements der Informationsverarbeitung. Obwohl hierbei die Leistung von DV-Systemen eine zentrale Rolle spielt, sind erst in neuerer ZeitFortschritte in Richtung auf eine objektive und vor allem benutzerorientierte Begriffs. und Methodenfestlegung gemacht worden.

Leistung als Qualitätsmerkmal der Datenverarbeitung gliedert sich in funktionale Eigenschaften (= Was kann es?), Schnelligkeitseigenschaften ( = Wie schnell kann es dies?) und Zuverlässigkeitseigenschaften ( = Wie beständig ist es in seiner Ausführungsbereitschaft?).

Das Wort Datenverarbeitungsleistung wird zunehmend für die Schnelligkeitsaspekte verwendet und gegen die Menge der funktionalen Eigenschaften und der Zuverlässigkeitseigenschaften abgegrenzt.

Die Probleme der bisherigen Leistungsmaße

Betrachtet man die derzeit eingesetzten Größen und Methoden zur Messung der DV-Leistung, zeigt sich, daß sie oft nicht auf die Bedürfnisse der Anwender eingehen. Sie waren für eine andere Zielgruppe gemacht, nämlich für die Gruppe der mit Systeminterna befaßten Spezialisten und Konstrukteure. Dem Anwender und Betreiber nützen nur solche Größen, welche die für ihn relevanten Aspekte beschreiben. Wie problematisch die bisher oft unbesehene Verwendung von Größen war, zeigt ein Beispiel mit Firmenangaben für zwei Modelle des IBM-Systems 6150 (sieche Tabelle 1).

Die Unterschiede in den Angaben sind enorm, und man weiß nicht, ob das neuere Modell nun 1,7mal schneller als das alte ist oder gar 40,5mal schneller oder ob keiner dieser Werte zutrifft.

Ähnliche Mängel in der Aussagekraft betreffen fast alle der früheren Leistungsmaße. Was nützt es zum Beispiel dem Endanwender, daß die CPU-Auslastung gut ist oder der Kiviatgraph** optimal? Dies besagt ja nur, daß die CPU beziehungsweise alle Systemkomponenten gleichmäßig und beschäftigt sind. Aber ob und wieviel sie zu einem Auftrag eines Anwenders beitragen, ersieht man daraus nicht, und man kann daraus auch nicht ableiten, welche Antwortzeiten der Benutzer an seinem Terminal abwartet oder welche Verweilzeit der Auftrag "Lohn und Gehalt zum 1. April 1992" hat. Das ersieht man auch nicht aus einer MIPS-Angabe (maximum possible million instructions of CPU per second).

Die ersten Ansätze zu stärkerer Anwenderbezogenheit waren die klassischen Batch-Benchmark-Tests. Sie beurteilten die Leistung anhand der Gesamtdurchlaufzeit für ein ausgewähltes Bündel von Programmläufen. Sie wurden eine gewisse Zeit der Szene gerecht, nämlich in der Periode der rein Batchorientierten Multiprogramming-Maschinen. Diese Methode verwendet die Programmpaket-Durchlaufzeit als Leistungsmaß. Die Benchmark-Tests verloren ihre Aussagekraft mit dem Aufkommen der interaktiven Systembenutzung (DB/DC-Systeme, Time-sharing-Anlagen etc.). Solchen Systemen versuchte man, durch Messung der Anzahl abgewickelter Aufträge/Transaktionen pro Zeiteinheit gerecht zu werden. Der Begriff des Durchsatzes rückte in den Vordergrund; er wurde zum Leistungsmaß.

Eine frühe Wurzel des Downsizing-Bestrebens

Den Anstoß zu einem wirklichen Durchbruch ergab aber erst ein großer Beschaffungswettbewerb, der wohl eine frühe Wurzel des heutigen Downsizing-Bestrebens darstellt. im zweiten Drittel der 80er Jahre unternahm der Hersteller Tandem den Versuch nachzuweisen, daß seine Systeme bezüglich des User-Nutzens besser oder mindestens gleichgut sein könnten wie die klassischen Lösungen für DB/DC-Systeme, welche wesentlich teurere proprietäre Mainframe-Systeme einsetzt.

Der Ansatz im berühmt gewordenen Debit-Credit-Test, (der dann von Tandem zum ET1 weiterentwickelt wurde) wurde, war verschiedene Klassen von Auftragsarten der Endbenutzer zu definieren und für jede Klasse eine Zeitforderung zur Erledigung festzulegen.

Eine solche Zeitforderung kann zum Beispiel lauten: Für mindestens 90 Prozent der Aufträge darf die Antwortzeit nicht über 2 Sekunden liegen. Es wird dann ein Meßversuch unter Realbedingungen vorgenommen, bei dem die Endbenutzer von einem Treibersystem simuliert wurden.

Tatsächlich konnte Tandem nachweisen, daß das eigene System mit geringeren Kosten als bei der Mainframe-Lösung alle Anforderungen der Endbenutzergesamtheit bezüglich der Ausführungszeit von Aufträgen erfüllt.

In dieser Methode wurde eine ganze Reihe neuer Erkenntnisse realisiert:

- Weder Durchlaufzeiten noch Durchsatzwerte für sich haben genügend Aussagekraft, um aus Endbenutzersicht ein System zu beurteilen. Es sind vielmehr beide Größen gleichzeitig zu betrachten. Dies ergab die Zusammenfassung und gleichzeitige Betrachtung von Durchsatz und Durchlaufzeit als Maß.

- Die Durchlaufzeiten sind an der Benutzer-Schnittstelle, nicht im Front-erid-Rechner oder gar systemintern zu messen, wobei das Netz einzubeziehen ist.

- Die Zeitforderungen, der Endbenutzer sind ein wesentlicher Bestandteil der Lastbeschreibung.

Seit einiger Zeit ist zu beobachten, daß der Einsatz von endbenutzerorientierten Leistungsmaßen zunimmt. Initiativen zu derartigen DV-Leistungsbewertungen sind:

- Programmpaket-Durchlaufzeit: Dieses Maß erlebt derzeit in der Marktnische der Superrechner, welche typischerweise weitgehend im Batch-Modus arbeiten, ein Comeback. Beispiele sind der Linpack-Benchmark oder der Perfect-Benchmark.

- Die Kernel-Methode wird von Spec System Performance Evaluation Cooperative zur benutzerorientierten Beurteilung von RISC-Maschinen unter Unix eingesetzt. Bei der Spec-Methode werden die Durchlaufzeiten ausgewählter und standardisierter Programme gemessen und mit den Laufzeiten auf der als Bezugsmaschine ausgewählten VAX11/780 verglichen.- Das Leistungsmaß Durchsatz kommt auf breiter Ebene zum Einsatz. Insbesondere die DV-Hersteller messen mit benutzersimulierenden Treibersystemen das Durchsatzverhalten ihrer Systeme bei der Entwicklung.

- Die Fortführung der Debit-Credit-Methode, die bis vor kurzem den methodisch weitestgehenden Ansatz darstellte, wird derzeit vom TPC (Transaction Processing Council) wahrgenommen und für DB/DC-Systeme mit Datenbankeinsatz verwendet. Die Hauptaussage dieser Methode ist die Anzahl der Transaktionen, die im Meßversuch mit einem benutzersimulierenden Treibersystem zustande kommen. Die Antwortzeit als zweite Aussage darauf, daß sie in 90 Prozent der Fälle einen vorgegebenen Grenzwert nicht überschreiten dürfen.

Schon sehr früh die Notwendigkeiten erkannt

Bei all diesen Aktivitäten handelt es sich um Hersteller- oder Anwenderinitiativen, während die nationalen oder internationalen Standardisierungsgremien, beispielsweise ISO und ANSI, passiv geblieben waren. Eine Ausnahme machte das Deutsche Institut für Normung (DIN).

DIN hat schon zu sehr früher Zeit die Notwendigkeit zu einer anwenderorientierten, objektiven Leistungsbeschreibung für DV-Systeme erkannt und unter großer Beteiligung von Anwendern und Herstellern ein Verfahren entwickelt, das diesen Bedürfnissen gerecht wird. Es ist in dem Ende 1991 erschienenen Teil 1 der Norm DIN 66273 niedergelegt.

Durchsatz und Durchlaufzeit gleichzeitig

Das DIN-Verfahren setzt (noch konsequente als der Debit-Credit-Test) Durchsatz und Durchlaufzeit gleichzeitig als Leistungsmaß ein. Weiterhin werden alle Leistungsgrößen auftragsartenspezifisch - und nicht gemittelt, wie dies andere Methoden zum Teil tun - angegeben. Die Zeitforderungen der Endbenutzer bezüglich der Durchlaufzeiten sind wie auch im Debit-Credit-Test wesentlicher Bestandteil der Lastbeschreibung. Gemessen wird mit einem externen Treiber. Er erzeugt die Aufträge - unter Einhaltung des vorgegebenen Mengengerüstes - in zufälliger Folge und ohne Zeitraffertechniken. Damit wird einerseits der Praxisbetrieb besonders realitätsnah nachgebildet, andererseits sind damit Manipulationsversuche zur Aufbesserung der Meßergebnisse nicht möglich.

Das DIN-Verfahren ist die am stärksten anwenderorientierte Methode. Sie versucht, nicht Leistungszahlen für DV-Systeme zu ermitteln, sondern die Hauptfrage des Anwenders zu beantworten. Diese lautet: "Wie gut erfüllt das System die Bedürfnisse einer konkreten Anwendergesamtheit?" Die DIN-Methode enthält deswegen neben dem Meßverfahren ein Bewertungsverfahren, das Durchsatz, Antwortzeit und Pünktlichkeit der Auftragserledigung bewertet (Bewertungsvektoren Ll bis L3; siehe Abbildung 3).

Bei der Frage nach der Maximalleistung eines DV-Systems geht DIN mit einem Sachverhalt, der lange Zeit von der DV-Welt ignoriert wurde und zum Teil heute noch wird, besonders konsequent um: Die maximale Leistung ist wegen der gegenseitigen Beeinflussung von Benutzerschnelligkeit und Maschinen- reaktion - der sogenannten Rückwirkung - nicht definierbar. Stellt man nämlich ein und dasselbe DV-System bei Mischlast einer schnelleren Benutzerschaft und einer langsameren Benutzerschaft gegenüber, dann erreicht es bei derselben Anzahl aktiver Terminals ganz unterschiedliche Durchsatz und Response-Zeit-Werte.

Es ist trotz vielseitiger Anstrengungen bis jetzt nicht gelungen in diesem vieldimensionalen Ereignisraum ein Maximum zu definieren, das einen brauchbaren praktischen Nutzwert hat. DIN verzichtet deshalb bewußt auf die Ermittlung und die Angabe von Maximal-Leistungswerten für DV-Systeme.

Um die Frage nach der Leistungsgrenze eines betrachteten Systems dennoch auszulosen, kann man dabei wie folgt vorgehen:

Man steigert unter Beibehaltung des Auftragsprofils der Endbenutzer in einer Meßserie die simulierte Benutzerzahl schrittweise. Dabei beobachtet man die Bewertungsvektoren. Sobald eine Komponente eines solchen Vektors unter 1 (dies ist die Grenze zwischen ausreichend und nicht genügend) kommt, ist die Leistungsgrenze erreicht.

Die Abbildungen zeigen eine solche Meßserie. Das DV-System erhält gleichzeitig drei Arten von Aufträgen.

AA2 und AA3 sind Batch-Auftragsarten, AA1 ist Dialog. Während bei n = 20 aktiven Terminals (jedes gibt Batch- und Dialogaufträge in vorgegebener Mischung ein) die mittleren Antwortzeiten noch ausreichen (L2-Werte über 1), weist die Termintreue (L3) aus, daß der kritische Punkt schon bei n = 15 aktiven Terminals liegt.

Dort gibt es die ersten Einbrüche für die Aufträge der Art AA2. Damit ist klar, daß das System bis zu 15 Benutzer dieser Art gut bedient und ab einer höheren Zahl Unzufriedenheit erzeugt.

Erfahrungen beim Einsatz der DIN-Methode bestätigen die Übereinstimmung der Bewertungsaussagen in erstaunlicher Weise mit den Beurteilungen der realen Endbenutzer.

Die DIN-Methode ist kein Hilfsmittel zur System- und Flaschenhals-Analyse für Tuner und Systembetreuer, aber sie kann in bisher nicht gekannter Klarheit sagen, wo ein System den Anwender gut oder schlecht bedient, und kann ebenso nachprüfen, ob und welchen Erfolg eine Tuning-Maßnahme oder ein System-Upgrade für die Benutzerseite tat sächlich bringt.

Anwendermitarbeit

Neben dem Verfahren selbst ist die Frage von Standardlasten von großer Bedeutung. Solche sind in Vorbereitung (zum Beispiel für Laborinformationssysteme, Textsysteme, Mainframes, DB/DC-Systeme), aber noch nicht normungsfähig. Diese Arbeit bedarf dringend der Mitarbeit von zahlreichen Anwendern aus allen Branchen*. Angemerkt sei noch, daß der Normtext des Teils 1 von DIN 66273 sehr knapp und nicht selbsterklärend ist. Es gibt deshalb Aktivitäten zur Anwenderunterstützung: In der Universität Kassel ist ein Arbeitsbuch zum DIN-Verfahren in Arbeit. DIN selbst hat ein Beiblatt in Vorbereitung (erläuternde Texte) und plant Seminare.