Zwischen der Transaktionszeit, der Transaktionsrate und der Anzahl Terminals besteht folgender grundlegender Zusammenhang:
(Denkzeit + Transaktionszeit) * Transaktionsrate = Anzahl der Terminals
Unter dem Begriff Transaktionszeit fasst man die Reaktion des Systems auf sehr unterschiedliche Anforderungen zusammen. Es ist deshalb schwer zu entscheiden, ob eine Transaktionszeit angemessen ist. Wegen der Kosten für den Betrieb der Terminals und die Arbeitszeit des Bedieners empfiehlt sich folgende Sicht:
Während der Transaktionszeit kann das Terminal nicht genutzt werden, da es auf den Server wartet. Während der Denkzeit arbeiten Terminal und Anwender durch Lesen der Ausgabe bzw. Eintippen einer neuen Eingabe. Der Anteil der Denkzeiten an der gesamten Belegungszeit des Terminals ist der Wirkungsgrad für Terminals E (Efficiency Value). Sinkt dieser im Mittel aller Terminals unter 75%, so ist das ein Anzeichen für Leistungsprobleme. Natürlich dürfen bei der Ermittlung der Denkzeiten "Verschnaufpausen" nicht mitgemessen werden.
Es seien:
TH (Think Time) die Denkzeit
TT (Transaction Time) die Transaktionszeit
TR (Transaction Rate) die Transaktionsrate
Für den Wirkungsgrad für Terminals (Efficiency Value, E) gilt laut Definition:
E = TH / (TH + TT)
Die Anzahl der je Sekunde für eine Anwendung zu bewältigenden Transaktionen sei TR. Dann errechnet sich die für diese Anwendung benötigte Anzahl K von Terminals zu
K = (TH + TT) * TR
K = TH / E * TR
Nimmt man einen Wirkungsgrad für Terminals von 0,75 an, so lautet die Formel:
K = 1,33 * TH * TR
Für verschiedene Wirkungsgrade gibt die folgende Tabelle die Werte für 1/E an.
E [%] | 70 | 75 | 80 | 85 | 90 | 95 |
1/E | 1,43 | 1,33 | 1,25 | 1,18 | 1,11 | 1,05 |
Die Formel E = TH / (TH + TT) lässt erkennen, dass für lange Denkzeiten auch eine entsprechend lange Transaktionszeit (bzw. Antwortzeit bei nur einer Antwort pro Transaktion) akzeptiert werden kann, während sich die Transaktionszeiten bei kurzen Denkzeiten nachhaltig auf den Wirkungsgrad und damit auf die Anzahl der benötigten Terminals auswirken.
Neben dem Wirkungsgrad bestimmt die Auslastung U (Utilization) des Terminals die Anzahl der benötigten Terminals. Die Auslastung ist der Anteil an der Gesamtzeit, in der das Gerät entweder auf Antworten wartet (Transaktionszeit) oder mit der Vorbereitung einer neuen Eingabe tätig ist (Denkzeit). Verschnaufpausen z.B. senken die Auslastung, ohne dass das Gerät wirklich frei ist. Bei einer Datenerfassungsanwendung werden i.d.R. Belege von einem Stapel abgearbeitet. Man kann die Arbeitsplätze daher sehr hoch auslasten.
Eine Auslastung der Terminals von 90% ist möglich. Ein kleiner Verlust von 10% wird für Verschnaufpausen eingeplant. Für andere Anwendungen muss die Auslastung geringer angesetzt werden. Bei TP-Betrieb mit Publikumsverkehr möchte man dem Kunden lästige Wartezeiten ersparen. Diese entstehen, wenn gerade kein Terminal frei ist und der Kunde deshalb nicht sofort bedient werden kann. Ähnliche Verhältnisse findet man in der Programmentwicklung. In diesen Fällen sollte die Auslastung U der Terminals 60% nicht überschreiten.
Dann errechnet sich die Anzahl der benötigten Terminals (K) zu:
K = (TH * TR) / (E * U)
Beispiel
Es existieren 2 Anwendungen:
Die erste Anwendung ist eine Datenerfassung mit einer Denkzeit von 20 Sekunden und einer Transaktionszeit von 1 Sekunde. Im Mittel sind immer 90% aller Erfassungsplätze tätig. Pro Stunde müssen 7.200 Belege erfasst werden.
Die zweite Anwendung ist eine Platz-Buchungsanwendung mit Publikumsverkehr. Die Denkzeit beträgt 120 Sekunden, die Transaktionszeit 3 Sekunden. Damit keine spürbaren Wartezeiten für die buchungswilligen Kunden entstehen, werden die Terminals nur zu 60% genutzt. 360 Buchungen pro Stunde sind abzufertigen.
E1 = 95%; U1 = 90%; TR1 = 2/s
(E1 = TH / (TH + TT) = 20s / (20s + 1s) = 0.95)
E2 = 97%; U2 = 60%; TR2 = 0.1/s
K1 = (20 * 2) / (0.95 * 0.90) = 47 Terminals
K2 = (120 * 0.1) / (0.97 * 0.60) = 21 Terminals
Für die beiden Anwendungen werden zusammen 68 Terminals benötigt. Es ist sicherzustellen, dass die im Wirkungsgrad für Terminals enthaltenen Vorgaben für die Transaktionszeit vom Server eingehalten werden können.
Dies ist die zu formulierende Leistungserwartung.
Sie kann nur eingehalten werden, wenn der Server durch den Betriebsmittelbedarf der Anwendung nicht überbeansprucht wird und noch gewisse Leistungsreserven hat. Dabei spielt die Belastung derjenigen Betriebsmittel eine besonders große Rolle, die von der betrachteten Anwendung stark genutzt werden. Ist die Anwendung mit vielen Ein-/Ausgaben auf Platten verbunden, dann ist für eine geringe Auslastung der Plattenlaufwerke zu sorgen. Zusätzliche freie Kapazitäten im Server bringen hier keine Verbesserung.
Umgekehrt ist es bei rechenintensiven Anwendungen.
Paging wirkt sich in beiden Fällen negativ aus.
Jede Transaktionszeit hat eine natürliche untere Grenze. Diese wird erreicht, wenn das Terminal seine Transaktion auf einem sonst völlig lastfreien Server mit ebenso lastfreien Datenübertragungswegen abwickelt. Eine solche Nutzung eines IT-Systems ist natürlich unwirtschaftlich. Kommen andere Terminals und ggf. andere Anwendungen hinzu, dann wird der Ablauf durch gegenseitige Behinderung der Transaktionen untereinander gedehnt.
Der Dehnfaktor (D) wird wie folgt definiert:
D = TT (aktuelle Belastung) / TT (leerer Server)
Die Dehnung ist der Preis für die wirtschaftliche Nutzung der Installation. Welche Dehnungen akzeptabel sind, hängt wieder von der Denkzeit und von der optimalen Transaktionszeit TT (leerer Server) ab. Bei kurzen Transaktionszeiten und langen Denkzeiten sind Dehnungen von 10 noch akzeptabel. Beträgt die optimale Transaktionszeit schon 3 Sekunden bei einer Denkzeit von nur 10 Sekunden, dann ist bereits die Dehnung 3 zu groß. Die optimale Transaktionszeit kann man entweder auf einem sonst betriebslosen Server messen oder nach folgender Formel abschätzen:
TT (leerer Server) = CPU + n * IO + NL
mit:
CPU für die Transaktion benötigte CPU-Zeit
IO mittlere Zeit für einen Ein-/Ausgabe-Vorgang
n Anzahl der für die Transaktion benötigten Ein-/Ausgaben (inkl. Paging)NL Netzlaufzeit für die Eingabe- und die Ausgabenachricht
Alle diese Werte sind durch Modifikationen an Hardware oder Software änderbar. Bei den CPU- und IO-Zeiten sind meist mehrere Tasks zu berücksichtigen, beim Transaktionsbetrieb etwa UTM- und DBH-Tasks.
Beispiel 1
Datenbankabfrage mit folgenden Werten:
CPU = 0,1s
IO = 0,004s
NL = 0,1s
n = 60
TT (leerer Server) = 0,1s + 60 * 0.004s + 0,1s = 0.44s
Bei einem Dehnfaktor von 3 für Server und Netz ergibt sich ein TTaktuell von
3 * 0.44 = 1.32 (= etwa 1.3). Mit einer Denkzeit von 40 Sekunden berechnet sich ein Wirkungsgrad für Terminals von 97%:
E = TH / (TH + TTaktuell) = 40s / (40s + 1.3s) = 0.97
Beträgt die Denkzeit nur 20 s, sinkt der Wirkungsgrad für Terminals auf 94%.
In diesem Fall wäre zu prüfen, ob sich die IO-Zeiten verringern ließen, etwa durch weniger Ein-/Ausgaben oder durch eine schnellere Peripherie.
Beispiel 2
Blättern im Editor mit folgenden Werten:
CPU = 0,01s
IO = 0,004s
NL = 1s
n = 2
TT (leerer Server) = 0.01s + 2 * 0.004s + 1s = 1.02s
Hier dominiert die Übertragungszeit des Ausgabebildschirms. Selbst bei einer Überlastung der Platten im Server (z.B. 0,025 s/IO) steigt die Transaktionszeit nur unmerklich auf 1,06 s. Bei einer Denkzeit von 3 Sekunden ergibt sich ein Wirkungsgrad für Terminals von 75%. Das ist unbefriedigend.
E = TH / (TH + TT) = 3s / (3s + 1.02s) = 0.746
Eine Verdopplung der Leitungsgeschwindigkeit führt hier zu einer optimalen Transaktionszeit von 0,53 s. Nimmt man an, dass während der Übertragung der Nachrichten keine Dehnungen auftreten, dann bleibt diese Transaktionszeit auch bei realistischer Last erhalten. Der Wirkungsgrad für Terminals steigt auf 85%.
Die beiden Beispiele zeigen, dass die Ursachen für eine unzureichende Leistung vielfältig sein können. Überlastungen in der CPU, in der Peripherie und Kombinationen von Engpässen können auftreten. Der Abschnitt "Prinzipielle Vorgehensweise" gibt Hilfen zum Aufdecken und Beseitigen solcher Probleme.
Die angeführten Formeln und Beispiele verdeutlichen, wie der Anwender seine Leistungserwartungen für den Online-Betrieb formulieren sollte. Das Ziel seines Handelns ist immer eine Kostenminimierung. Rechnet man die Einsparungen auf der einen Seite
(z.B. für Personal und Terminals) gegen die Mehrkosten (z.B. für schnellere Leitungen, schnellere Rechner, schnellere Platten oder Programmänderungen) auf der anderen Seite auf, dann kommt man immer zu einer fundierten Leistungserwartung. Unter Berücksichtigung der Preisbewegungen für die Hardware sollten die gefundenen Entscheidungen in gewissen Zeitabständen überprüft werden.
Natürlich dürfen subjektive Gesichtspunkte nicht ganz vernachlässigt werden, etwa die psychologisch schädliche Wirkung gelegentlicher langer Transaktionszeiten. Die darauf aufgebauten Leistungserwartungen führen jedoch auf Irrwege. Die Beseitigung einzelner langer Transaktionszeiten ist meist sehr aufwändig und führt i.d.R. nicht zu generellen Einsparungen.