Das Deutsche Institut für Normung (DIN) arbeitet seit längerem an einer Normung zur Leistungsmessung und Bewertung von DV-Systemen. Nun legte DIN den Entwurf des Teils 1 dieser Norm vor, der das Meßverfahren regelt**. DIN ist nicht nur weltweit das erste Gremium, das hierzu eine Norm anbietet. Vielmehr befindet sich DIN auch methodisch an vorderster Front und darf als Schrittmacher angesehen werden.
"DIN macht Rechnerleistung vergleichbar" war im Januar 1988 in der CW zu lesen. Damals wurde von den Bestrebungen des Deutschen Instituts für Normung zur Schaffung eines Standards zur Leistungsmessung und Bewertung von DV-Systemen berichtet und eine neue Norm angekündigt. Der Plan von DIN sah wie folgt aus: Die Norm mit der Nummer 66273 besteht aus mehreren Teilen. Teil 1 definiert den Leistungsbegriff, die Meßgrößen, die Beschreibungsmethodik für Lasten und legt das Meßverfahren fest. Die Teile 2 und folgende legen Standardlisten für solche Bereiche fest, in denen es möglich und sinnvoll ist, repräsentative Lasten zu benennen. Für die Teile 2 ff. stehen auf der Liste: Timesharing-Benutzung von Rechenanlagen auf Kommandossprachen-Ebene (zum Beispiel Rechner in der Programmentwicklung), Dialoganwendungen wie zum Beispiel Textverarbeitung, Online-Transaktionssysteme wie Cash-and-Carry-Systeme etc. Jeder Teil der Norm besteht aus einem eigentlichen Normteil (mit einer knappen und sehr straffen Formulierung der Normaussagen zum jeweiligen Sachbereich) sowie einem Beiblatt, das ergänzende Erklärungen, Hinweise für den Anwender und ähnliches gibt; letztere sind aber nicht bindend im Sinne einer Normaussage.
Doch hat die Normarbeit etwas länger gedauert als damals geplant war, aber DIN kann jetzt doch erste Früchte seiner beharrlichen und schon vor einem Jahrzehnt begonnenen Arbeiten ernten. DIN ist bezüglich des Aufbaus der Norm bei seinem obengenannten Plan geblieben und hat nun den Teil 1 fertig gestellt. Die Sacharbeit hat der Unterausschuß UA7.3 "Messung und Bewertung der DV-Leistung" geleistet. Er ist ein Gremium, das gemeinschaftlich von Anwendern, Behörden, Industrie, wissenschaftlichen Instituten
etc. getragen wird.
Anwender und Hersteller an einem Tisch
Speziell vom UA7.3-Ausschuß kann man feststellen, daß er in ausgewogener Mischung Anwender und Hersteller an einen Tisch brachte. Als erstes Ergebnis seiner Arbeit erscheint der Norm-Entwurf DIN 66273, Teil 1 jetzt im März. Damit legt DIN weltweit als erstes Standardisierungsgremium eine Verfahrensnorm zur Lastbeschreibung, Leistungsmessung und Bewertung vor. Dieses ist bemerkenswert, denn trotz großem allgemeinen Interesse an dieser Materie ist bei keinem nationalen oder internationalen Standardisierungsgremium (ANSI, ISO, ECMA . . . ) bis jetzt eine Norm dazu erschienen. Damit ist DIN trotz etwas verspätetem Zeitplan führend. Das einzige Normungswerk zu Performancefragen, das es bis jetzt gibt, stammt ebenfalls von DIN, nämlich von der Deutschen Elektrotechnischen Kommission. Es beschreibt unter der Nummer 19242 einen "Leistungstest von Prozeßrechensystemen" und geht damit auf ein sehr spezielles Thema ein. Dort wird für das methodisch schon länger bekannte Kernel-Verfahren ein Satz von Meßprogrammen für den speziellen Bereich der Prozeßrechner festgelegt, während DIN 66273, Teil 1 eine wesentlich allgemeinere Aufgabenstellung für einen breiten Bereich von DV-Anwendungen abdeckt.
Timesharing-Scripts und Whetstone-Test helfen
Das besondere Anliegen dieser Norm ist es, dem Anwender eine Methode zu geben, um DV-Systeme aus seiner Sicht und gemäß seinen Bedürfnissen vermessen und objektiv vergleichen zu können. Die Uralt-Maße beziehungsweise Verfahren hierzu, wie MIPS, Batch-Benchmark und so weiter sind aus den bekannten Gründen unzureichend.
Aber auch Meßzahlen aus neueren Verfahren wie Whetstone-Test oder Timesharing-Scripts helfen wenig, wenn es um die Kernfrage des Anwenders geht. Sie lautet nicht, wie schnell ein spezielles Teilproblem bearbeitet wird, sondern sie lautet, ob und wie das System mit der Gesamtlast, die vom Unternehmen auf die Rechenanlage einfließt, fertig wird, und ob es dabei die zeitlichen Randbedingungen (ausreichend online/Dialog-Antwortzeiten, Gleichzeitig termingerechte Fertigstellung der Batchaufgaben, parallel dazu Timesharing-Betrieb mit befriedigenden Reaktionszeiten etc. ) einhält. Diese Problematik erwies sich - obwohl vieldiskutiert - bezüglich der Meßmethodik und der Lastbeschreibung nirgends als befriedigend gelöst und war Neuland. Der UA7.3 hat sich daher längere Zeit in die Grundlagenbetrachtung vertieft, Erfahrungen von Größtanwendern (wie Lufthansa) zu Rate gezogen und neuere theoretische Untersuchungen verwertet.
Das nun von DIN vorgestellte Verfahren schafft die Möglichkeit, die Gesamtlast eines DV-Systems knapp, aber genau mit gerade denjenigen Kriterien zu Beschreiben die durch die insgesamt zu bewältigenden Anwendungen vorgegeben sind. Das System wird dabei aus, schließlich bezüglich seiner Reaktionen an der Benutzerschnittstelle beschrieben (Auftragsarten, Auftragsbearbeitungszeiten . . . ) Es wird ansonsten als Black-Box betrachtet. Diese entspricht der Sicht des Endusers, denn die innen ablaufenden Vorgänge (und dazu gehörenden Meßgrößen wie Prozessorauslastung, Instruktionsraten, Kanalgeschwindigkeiten und so weiter) sind für ihn weder sichtbar, noch interessierter sich für sie wirklich.
Dementsprechend betrachtet DIN nur den Auftragsstromder zumSystem hinfließenden Aufträge (sie werden mittels der auftragsspezifischen Auftragsraten beschrieben) und den Strom, der vom System zurückkommenden Auftragsergebnisse beziehungsweise Systemantworten. Bei den letzteren wird - wieder auftragsspezifisch - unterschieden zwischen zeitgerecht erledigten und verspätet gekommenen. Nur die zeitgerecht erledigten zählen im Sinne von DIN zu der vom System erbrachten Leistung, während Aufträge, deren Resultat jenseits der vom Benutzer geforderten Erledigungszeiten liegen, als unerledigt (und damit nicht zur erbrachten Leistung zählend) betrachtet werden.
Gestuftes System von Ausreißerklassen
Um Ungerechtigkeiten zu vermeiden, hat DIN hierzu ein gestuftes System von Ausreißerklassen für die Fertigungszeiten, welche noch toleriert werden, eingerichtet. Weiterhin zeigt DIN - und das ist auch ein Novum - wie allein aus der Lastbeschreibung und den darin enthaltenen Benutzerforderungen die vom System geforderte Leistung ermittelt werden kann. Dieser Wert wird als Leistungsreferenzwert zur Beurteilung vermessener Systeme verwendet. Das Messen erfolgt mittels synthetischer Last und Treiber. Dieses Vorgehen legt in einer objektiven und jederzeit wiederholbaren Weise klar, welches der vermessenen Systeme die Bedürfnisse der Endanwender erfüllt und welches dies nicht kann. Dabei wird ausgewiesen, bei welchen Auftragsarten Unter- beziehungsweise Überleistungen auftreten und in welcher Höhe diese liegen. Die Methodik ist universell und erlaubt es, die Menge aller dem System aufgetragenen Online- und Batch-Anwendungen zu beschreiben, zu vermessen und zu bewerten.
Nachfolgend sei auf einige Aspekte näher eingegangen. Dabei sind diese beispielhaft herausgegriffen, und auf eine flächendeckende Behandlung aller Punkte wird verzichtet.
Breites Gremium suchte die bessere Meßmethode
Die von DIN vorgeschlagene Methode wurde von dem sehr ausgewogen zusammengesetzten Arbeitskreis UA7.3 erarbeitet. Es wirkten namhafte Anwender und wichtige DV-Hersteller mit und die Methode wird damit von einer breiten Basis getragen (herstellerseits unter anderem IBM, Siemens, Nixdorf, DEC, Prime, Unisys, anwenderseits unter anderem Lufthansa, BASF, FTZ, Post). Daß nun gerade ein so breites Gremium nicht den Weg des geringsten Widerstandes (zum Beispiel Festsetzung einiger Benchmarkprogramme oder Timesharing-Scripts als Norm-Meßprogramme) gegangen ist, sondern intensive Arbeit in die Suche nach einer besseren Meßmethode gesteckt hat, zeigt, daß man Performance-Messung und -Bewertung als ein komplexes Thema begriffen hat, bei dem es nicht gelingen kann mit irgendeiner simplen Methode zu arbeiten und dann gar noch aussagekräftige, objektive Meß- und Bewertungsgrößen in Form von ein oder zwei skalaren Allerweltszahlen zu finden. Der Arbeitskreis war sich, basierend auf Großanwendererfahrungen, schon sehr früh im klaren, daß eine differenzierende Methode nötig ist und hat unter anderem vektorielle Größen eingeführt.
Aus Erfahrungen wie der, daß Timesharing-Reaktionszeiten nichts über den Gesamtdurchsatz einer Maschine aussagen und andererseits die besten Durchsatzwerte nichts nützen, wenn die Bearbeitungszeiten im Rechner zu lang sind, hat sich der Arbeitskreis - auch schon in sehr frühem Stadium der Arbeit - entschlossen, die beiden Aspekte wie folgt zu integrieren: Die Bewertung orientiert sich an auftragsspezifischen Auftragsraten. Dies ergibt unter anderem die (vektorielle) Größe "erbrachte Leistung". Sie enthält für jede der Auftragsarten die Ratezeitgerecht erledigter Aufträge.
Bei den Auftragsarten wird die frühere Unterscheidung in Online-Tasks und Batch-Hintergrundfarben aufgegeben. Diese Auftragstypen werden einheitlich behandelt. Sie unterscheiden sich ja nicht grundsätzlich, sondern nur durch den Zeitmaßstab. Bei Online ist man eben gewohnt in Verweilzeiten von Sekunden und beim Batch in Stunden zu denken. Die Beschreibung der Leistungseigenschaften mittels der Raten von Enduser-Aufträgen ergibt Größen, die sehr nahe an den Interessen der Benutzer beziehungsweise Anwender liegen.
Auch komplexeste Lasten großer Systeme
Zwar ist die Beschreibungstechnik der DIN-Methode imstande auch umfangreichste und komplexeste Lasten von großen Systemen zu beschreiben, sie kann aber ebenso in ganz einfacher vergröbernder Weise benutzt werden. Sie ist äußerst flexibel und legt es in das Ermessen des Anwenders wie differenziert er gemessen und bewertet haben will .
Für ein Online-Transaktionssystem mit Datensicherung im Hintergrund könnte man zum Beispiel mit Vektoren von nur zwei Komponenten auskommen. Dann würde der Vektor der erbrachten Leistung zum Beispiel folgende Aussage machen: 27 Transaktionen pro Minute und gleichzeitig drei Save-Läufe pro Schicht. Dabei sind diese Zahlen als zeitgerecht erledigte Aufträge verstanden und bezogen auf einen Dauerbetrieb, das heißt es dürfen durch die Save-Läufe keine Reaktionszeiteinbrüche bei den Transaktionen geschehen.
Der Anwender könnte auch den Wunsch haben, die gesamten Transaktionen sehr fein nach Transaktionsarten zu unterscheiden und käme dann zum Beispiel zu acht Arten und gegebenenfalls noch einer Unterscheidung der Save-Läufe in zwei Arten, womit dann der Vektor zehn Komponenten hätte.
Ein wichtiger Aspekt ist, daß die Methode als wesentliches Element der Lastbeschreibung die Zeitforderungen des Endusers aufnimmt. Wenn zum Beispiel ein Auslieferungslager fünfmal am Tage Lieferlisten braucht, die jeweils zwei Stunden nach Abgabe der Rohdaten fertig sein müssen, dann nützt ihm ein DV-System, das zwar 1000 solcher Jobs in der Woche schafft, aber bei jedem Job vier Stunden Verweilzeit auflaufen läßt, gar nichts, obwohl dieses System in "Lieschen-Müller"-Denkweise zigmal leistungsstarker wäre als eines, das die fünf Lieferzeiten pro Tag schafft (bei zwei Stunden Verweilzeit). Analoges gilt für Online-Reaktionszeiten.
Die Denkweise, daß nur zeitgerecht erledigte Aufträge einen Nutzen bringen, verspätete Auftragsergebnisse aber nicht, führt zu Maßzahlen, die betriebswirtschaftlichen Größen sehr verwandt sind und damit nicht nur dem Enduser anwendernahe Aussagen machen, sondern darüber hinaus vom Management, vom Controller, von Betriebswirten oder von Entscheidungsträgern angewendet werden können.
"Maximale Leistung" kann nicht hergeleitet worden
Die DIN-Arbeitsguppe war sich ganz klar darüber, daß jedwede Messung (ob mit Treiber wie hier vorgesehen oder im realen Betrieb mit wirklichen Benutzern) immer nur eine beschränkte Leistungsaussage geben kann, nämlich wie sich das betrachtete DV-System unter genau dieser Last verhält. Welche Werte sich für die erbrachte Leistung bei mehr oder weniger aktiven Online-Benutzern und/ oder mit mehr oder weniger sonstigen Aufträgen im System einstellen, kann aus dem Meßergebnis nicht zwingend gefolgert werden. Insbesondere kann daraus nicht eine Größe wie die "maximale Leistung" des Systems hergeleitet werden. Aber auch mehrere Meßversuche führen zu keiner eindeutigen Aussage, denn die Last ist ein komplexer Sachverhalt und kann auf beliebig viele unterschiedliche Arten verändert beziehungsweise gesteigert werden. Welche davon sollte man als maximal ansehen? DIN hat deswegen bewußt auf den Begriff einer Maximalleistung verzichtet. Das mag manchem, der für sein DV-System gern eine PS-Zahl wie beim Auto hören möchte, sauer aufstoßen. DIN zeigt, daß hier ein Umdenken erforderlich ist. Aber DIN zeigt einen Ausweg in Form der Einführung einer Referenzleistung auf. Diese ist ein Novum und heißt bei DIN Grenzleistung. Die Grenzleistung ist ein aus dem Mengengerüst der Benutzerbedürfnisse direkt herleitbarer Vektor, der für die Auftragsarten angibt, mit welchen Raten sie (zeitgerecht!) gleichzeitig erledigt werden müssen, um die End-user-Gemeinschaft zu befriedigen. Die Grenzleistung - sie ist ohne jede Messung direkt aus dem Auftragsprofil, dem Denkzeitverhalten, der Benutzerschaft etc. ableitbar. Sie ist eine Meßlatte, die dem Anwender handfest hilft. Daran, daß es eine solche Größe gibt, muß man sich gegebenenfalls erst gewöhnen.
Tests mit breitem Personenkreis gemacht
Ein ganz anderer Aspekt ist die Frage der Akzeptanz der Norm. Es wurden Tests mit einem breiten Personenkreis gemacht und folgendes festgestellt:
- Alte Systemhasen sind mehrheitlich schlichtweg entsetzt. Sie lehnen zum Teil glatt ab. Sie sehen ihre Felle davonschwimmen. Keine ihrer liebgewonnenen Größen (wie Kanalraten, MIPS-Werte, Dehnungsfaktoren, Speicherzugriffszeiten, Auslastungsgrößen) finden sie wieder. Die Beurteilung ihres so komplexen Spielzeuges wird rüde auf die banale Ebene des Enduser-Nutzens herabtransformiert. Der ganze Geist der in einer chromblitzenden CPU mit höchsten Raffinessen des Pipelining steckt, wird nicht mehr gewürdigt. Das ist die eine Seite, das psychologische Problem. Die andere, die inhaltliche ist, daß Systemleute gewohnt sind primär interne Größen, die sie für die Analyse des Systemgeschehens brauchen, zu benutzen. Dagegen haben sie das Verhalten des Systems an der Außenhaut (also enduser-orientierte Größen) selten im Blickfeld. Die Welt ist für sie ungewohnt. - Anwender konnten sich je größer je leichter - relativ schnell in das zum Teil neue Gedanken gut einleben und es anwenden. Ein Problem war allerdings, daß die Anwender oft nicht gewohnt waren exakt zu beschreiben was sie eigentlich vom System wollten. Zum Beispiel wollten manche ganz naiv das "beste" von mehreren zur Wahl stehenden Systemen. So etwas ist nicht entscheidbar. Vielmehr muß der Anwender und da wirkt die DIN-Methode erzieherisch, klipp und klar seine Bedürfnisse (ausgedruckt in Reaktionszeitvorgaben, Terminen, Auftragsarten, Denkzeitangaben und andere) feststellen. Dann kann in einem zweiten Schritt mit dem Referenzwert "Grenzleistung" ausgesagt werden, welche Systemleistung zu erbringen wäre. Im dritten Schritt kann dann bewertet werden, welches der vermessenen Systeme die Bedürfnisse erfüllt, wieviel gegebenenfalls Überleistung vorliegt oder welche Leistungsdefizite bestehen.
DIN wünscht eine rege Mitarbeit
- Junge Informatiker haben Überhaupt kein Problem. Sie lesen sich ein, haben es in Kürze verstanden und wenden es problemlos an. Alte Informatiker tun sich zum Teil schwerer; sie schleppen unter Umständen Altlasten wie die alten Systemhasen mit sich herum und verhalten sich gegebenenfalls dann in dieser Richtung.
Der Norm-Entwurf 66273, Teil 1 (Methode) ist vor kurzem erschienen und ist beim DIN (Berlin, Burggrafenstraße) erhältlich. In Vorbereitung ist das Beiblatt zum Teil 1. Für dessen Erscheinen gibt es aber noch keinen festen Termin. Ebenso gibt es noch keine Termine für die Herausgabe der weiteren Teile, in denen dann Normlasten beschrieben werden. Im Hinblick darauf wünscht sich DIN eine rege Mitarbeit aller Anwenderbereiche (zum Beispiel Textverarbeitung, Bankanwendungen, Standard-Branchen-Anwendungen wie FiBu) und ruft alle Interessierten zur Mitarbeit auf. Näheres ist bei DIN (Ansprechpartner Herr Kutschke vom UA7.3) zu erfahren. Die DIN-Methode wurde natürlich nicht ohne parallel laufende Einsatzversuche entwickelt. Aktivitäten gibt es an verschiedenen Stellen, unter anderem im Kasseler Rechenzentrum. Dort ist - um dem Bedürfnis nach einfahrender Schriften nachzukommen - eine Benutzereinführung für den Praktiker in Vorbereitung.