Multiple Aufgaben

Was in Wirklichkeit sehr häufig vorkommt, ist, dass eine einzelne Ressource, etwa ein Datenbankserver, mit verschiedenen Transaktionstypen umgehen muss. Zum Beispiel kann der Kauf eines Flugtickets oder die Buchung eines Hotelzimmers im Internet ein halbes Dutzend unterschiedliche Transaktionen erfordern, bevor das Ticket ausgestellt oder das Zimmer endlich reserviert ist. Situationen dieser Art lassen sich wie folgt mit PDQ abbilden.

Man betrachte den einfacheren Fall von drei unterschiedlichen Transaktionstypen, die durch die Farben Rot, Grün und Blau gekennzeichnet werden. Jede dieser eingefärbten Aufgaben kann auf eine gemeinsam genutzte Ressource zugreifen, zum Beispiel einen Datenbankserver. Im Warteschlangenparadigma ( Abbildung 16 ) wird jede der bunten Aufgaben durch die unterschiedlichen Bedienzeiten charakterisiert. Mit anderen Worten: Die rote Last erhält eine rote Bedienzeit, die grüne eine grüne Bedienzeit und so weiter. Für jede Farbe gilt auch eine eigene Ankunftrate.

Abbildung 16: PDQ-Modell einer Warteschlange mit multiplen Aufgaben.

Geht man davon aus, dass sich die Bedienzeiten unterscheiden, resultiert die tatsächliche Auswirkung auf die Warteschlange beim Eintreffen beispielsweise einer roten Anforderung nicht mehr allein aus der Anzahl von bereits wartenden Anforderungen (das trifft nur für eine "monochrome" Aufgabe zu), sondern aus der Farbkombination der wartenden Anforderungen. In PDQ lässt sich Abbildung 16 vielleicht so darstellen wie im Listing 5 .

Natürlich ist der durch multiple Aufgaben generierte PDQ-Report komplexer aufgrund der vielen möglichen Interaktionen. Auf jeden Fall wirft er etwas Licht auf die vielfältigen Erweiterungsmöglichkeiten von PDQ, um realistische Computerarchitekturen abbilden zu können. Diese Thematik noch weiter auszuführen, würde den Rahmen sprengen, aber man findet weitere Details in [5] .

Richtlinien für den Einsatz von PDQ

Modelle jeder Art zu erstellen, ist teils Wissenschaft und teils Kunst, und daher ist es unmöglich, ein komplettes Regelwerk oder eine komplette Sammlung von Algorithmen bereitzustellen, die immer das richtige Modell liefern. Wie dieser Artikel illustriert, handelt es sich in Wirklichkeit um einen Prozess der ständigen Verbesserung. Erfahrung ist durch nichts zu ersetzen, und sie gewinnt man bekanntlich durch die ständige Wiederholung.

In diesem Sinne folgen nun einige Richtlinien, die unter Umständen helfen, wenn man PDQ-Modelle kreiert: .

• Keep it simple: Ein PDQ-Modell sollte so einfach wie irgend möglich sein, aber auch nicht einfacher. Es ist kaum zu vermeiden, dass man um so mehr Details in das PDQ-Modell stopfen möchte, je mehr man über die Systemarchitektur weiß. Das führt jedoch unausweichlich zu einer Überlastung des Modells.
• Eher die Streckenkarte als die U-Bahn im Hinterkopf behalten: Ein PDQ-Modell verhält sich zum Computersystem wie eine Karte der U-Bahn zum physikalischen U-Bahn-Netz. Eine U-Bahn-Karte ist eine Abstraktion, die kaum etwas mit der physischen Beschaffenheit des Netzes zu tun hat. Sie bietet gerade ausreichende Details, sodass man von Punkt A nach Punkt B kommt. Sie enthält jedoch keine überflüssigen Details wie die Höhe der Bahnhöfe über Normalnull, ja noch nicht einmal die Entfernung zwischen ihnen. Ein PDQ-Modell ist eine ähnliche Abstraktion.
• Das große Bild: Im Gegensatz zu vielen Aspekten der Computertechnologie, bei denen man große Mengen winziger Details aufnehmen muss, geht es beim PDQ-Modell darum, zu entscheiden, wie viele Details man ignorieren kann!
• Suchen nach dem Operationsprinzip: Wer das Operationsprinzip nicht in weniger als 25 Worten beschreiben kann, versteht es wahrscheinlich nicht gut genug, um mit dem Aufbau eines PDQ-Modells zu beginnen. Das Operationsprinzip für ein Timesharing-Computersystem lässt sich beispielsweise wie folgt ausdrücken: Timesharing gibt jedem Benutzer die Illusion, dass er der einzige aktive Benutzer des Systems ist. Die Hunderte Zeilen Code in Linux, um Timeslicing zu implementieren, dienen lediglich dem Zweck, diese Illusion zu untermauern.
• Den schwarzen Peter weitergeben: Beim PDQ-Modeling geht es auch darum, die Verantwortung zu verteilen. Als Performance-Analyst muss man lediglich das Leistungsproblem aufdecken – dann tritt man beiseite und lässt es die anderen beheben.
• Wo anfangen? Oder "Spaß mit Bauklötzen": Ein möglicher Ausgangspunkt für ein PDQ-Modell wäre ein Diagramm mit Funktionsblöcken. Das Ziel dabei ist, zu erkennen, wo in welcher Phase Zeit für die Verarbeitung der zu untersuchenden Aufgabe aufgewendet wird. Letztendlich wird jeder Funktionsblock in ein Warteschlangensubsystem umgewandelt. Dabei kann man zwischen der sequenziellen und parallelen Verarbeitung unterscheiden. Andere, ebenfalls auf Diagrammen basierende Techniken, beispielsweise UML-Diagramme, können außerdem nützlich sein.
• Input und Output: Beim Definieren eines PDQ-Modells ist es nützlich, eine Liste der Inputs (Messungen oder Schätzungen, die zum Parametrisieren des Modells eingesetzt werden) und Outputs (Zahlen, die sich durch die Berechnung des Modells ergeben) aufzustellen.
• Analog zur Regel fürs Restaurant: "Keine Schuhe, keine Bedienung!" lautet die Regel für PDQ-Modelle: Keine Bedienung, keine Warteschlange. In PDQ-Modellen ist es sinnlos, Warteschlangenknoten zu erstellen, für die es keine gemessenen Bedienzeiten gibt. Wenn die Messungen des echten Systems keine Bedienzeit für einen zu modellierenden PDQ-Knoten enthalten, dann lässt sich der Knoten nicht definieren.
• Bedienzeiten schätzen: Bedienzeiten lassen sich oft nur schwer direkt messen. Aber oft lässt sich die Bedienzeit aus anderen Leistungsmetriken ableiten, die sich leichter überwachen lassen. Siehe dazu Tabelle 4 .
• Ändern der Daten: Wenn die Messungen nicht zum PDQ-Leistungsmodell passen, müssen die Messungen wahrscheinlich wiederholt werden.
• Offene oder geschlossene Warteschlange? Wenn man überlegt, welches Warteschlangenmodell anzuwenden ist, fragt man sich, ob die zu verarbeitende Menge an Anforderungen endlich ist. Lautet die Antwort "ja" (und das sollte sie beispielsweise für eine Lasttestplattform immer sein), dann handelt es sich immer um ein geschlossenes Warteschlangenmodell. In allen anderen Fällen benutzt man am besten ein offenes Warteschlangenmodell.
• Messungen im stabilen Zustand: Die Dauer der Messung im stabilen Zustand sollte in einer Größenordnung liegen, die um den Faktor 100 größer ist als die längste auftretende Bedienzeit.
• Welche Zeiteinheit sollte man verwenden? Am besten benutzt man immer die Zeiteinheit des Messtools. Wenn das Tool also in Sekunden misst, dann verwendet man Sekunden; misst es Mikrosekunden, tut man es ihm gleich. Wer mehrere Datenquellen zugleich überwacht, der sollte stets zuerst alle Messwerte auf die gleichen Einheiten umrechnen, und erst danach mit der Modellierung beginnen.
• Aufgaben treten in der Regel in Dreiergruppen auf: In einem gemischten Aufgabenmodell (Multiclass-Streams in PDQ) vermeidet man die Nutzung von mehr als drei gleichzeitigen Aufgabenstreams, wo immer das möglich ist. Davon abgesehen, dass der resultierende PDQ-Report ansonsten ganz bestimmt unhandlich ist, interessiert man sich in der Regel lediglich für die Interaktion zweier Aufgaben, das heißt für einen Vergleich von Aufgabenpaaren. Alles andere gehört zur dritten Aufgabe (dem "Hintergrund"). Wenn man nicht erkennen kann, wie dieses Problem praktisch zu lösen wäre, dann ist man wahrscheinlich noch nicht so weit, das PDQ-Modell erstellen zu können.