Fujitsu 68 사용자 설명서
White Paper | Sizing Guide | Terminal Server Sizing Guide
Ausgabe: 3.3 | Dezember 2006
Die Antwortzeit ist die Zeit von dem Tastendruck bis zur Anzeige der Zeichenfolge. Um die Antwortzeit
genau messen zu können, wird der Messwert anhand von zwei Ausgangszeitwerten t
genau messen zu können, wird der Messwert anhand von zwei Ausgangszeitwerten t
1
und t
2
aus einer
Referenzzeitquelle berechnet bevor und nachdem ein Tastendruck gesendet wurde. t
1
ist die Zeit wenn der
Test Controller die Instruktion zum Client sendet und t
2
repräsentiert die Zeit wenn der Client den Tasten-
druck zum Server sendet. Eine dritte Messung t
3
wird durchgeführt, wenn die betreffende Zeichenfolge vom
Client empfangen worden ist. Die Zeit wird in Millisekunden gemessen. Basierend auf diesen Messwerten
wird die Antwortzeit im Intervall (t
wird die Antwortzeit im Intervall (t
3
– t
2
, t
3
– t
1
) veranschlagt. In der Praxis ist der Messfehler (die Zeit
zwischen t
1
und t
2
) geringer als 1 Millisekunde und die Antwortzeiten sind angenähert t
3
– t
1
.
Für jedes Szenario startet die Test Controller-Arbeitsstation Gruppen von zehn Clientverbindungen auf den
Arbeitsstationen mit einem Abstand von 30 Sekunden zwischen den Verbindungen. Nachdem eine Gruppe
von zehn Clientverbindungen gestartet wurde, wird ein Stabilisationszeitraum von fünf Minuten abgewartet,
in der keine weiteren Sitzungen gestartet werden. Nach diesem Zeitraum startet das Knowledge Worker
Skript die vier Anwendungen, die während des Tests genutzt werden, innerhalb von 5 Minuten. Dies
verhindert jegliche Beeinflussung zwischen den einzelnen Gruppen der zehn Clientverbindungen.
Arbeitsstationen mit einem Abstand von 30 Sekunden zwischen den Verbindungen. Nachdem eine Gruppe
von zehn Clientverbindungen gestartet wurde, wird ein Stabilisationszeitraum von fünf Minuten abgewartet,
in der keine weiteren Sitzungen gestartet werden. Nach diesem Zeitraum startet das Knowledge Worker
Skript die vier Anwendungen, die während des Tests genutzt werden, innerhalb von 5 Minuten. Dies
verhindert jegliche Beeinflussung zwischen den einzelnen Gruppen der zehn Clientverbindungen.
Mit steigender Benutzeranzahl wird für jede Aktion ein Punkt der Verschlechterung festgelegt, bei dem die
Antwortzeiten sich auf einen Wert verschlechtern, der als signifikant erachtet wird.
• Für Aktionen, die anfangs eine Antwortzeit von weniger als 200 ms besitzen, ist der Punkt der
Antwortzeiten sich auf einen Wert verschlechtern, der als signifikant erachtet wird.
• Für Aktionen, die anfangs eine Antwortzeit von weniger als 200 ms besitzen, ist der Punkt der
Verschlechterung erreicht, wenn die durchschnittliche Antwortzeit über 200 ms liegt und 110% der
anfänglichen Antwortzeit überschreitet.
anfänglichen Antwortzeit überschreitet.
• Für Aktionen, die anfangs eine Antwortzeit von mehr als 200 ms besitzen, ist der Punkt der
Verschlechterung erreicht, wenn die durchschnittliche Antwortzeit die anfängliche Antwortzeit um 10%
überschreitet.
überschreitet.
Dieses Kriterium basiert auf der Annahme, dass ein Benutzer eine Verschlechterung der Antwortzeiten bei
Zeiten unter 200 ms nicht bemerkt.
Zeiten unter 200 ms nicht bemerkt.
Dieser Test unterstützt das vorherige Testsystem, bei dem der Grenzwert der Systemlast durch ein so
genanntes »Canary« Skript ermittelt wurde, das in der stabilen Phase zwischen den Logon-Gruppen ablief.
Das Canary Skript wurde zum Ablauf gebracht, bevor sich ein Benutzer am System angemeldet hatte, und
die Zeit, die das Skript für einen Durchlauf benötigte (verstrichene Zeit), wird aufgezeichnet. Diese
verstrichene Zeit ist die Baseline, sie wird als Grundlinie für die Antwortrate in einer gegebenen
Serverkonfiguration erachtet. Mit dieser Methode wurde das Erreichen der maximalen Last festgelegt, wenn
die Gesamtzeit für einen Durchlauf des Canary Skripts um 10% höher als der Ausgangswert war. Die
Antwortzeit-Methode wird jedoch als genauer angesehen, da sie als Schlüsselparameter die momentane
Benutzer Erfahrung misst, auch den Einfluss der Logon-Phasen mit berücksichtigt und mehr Daten für eine
Entscheidungsfindung bereitstellt. Die »Canary« Skript-Methode kann aber in Konfigurationen effizienter
sein, die nur eine kleine Anzahl Benutzer betreiben und bei denen die Antwortzeit-Methode keine genügende
Menge an Antwortzeiten liefert.
genanntes »Canary« Skript ermittelt wurde, das in der stabilen Phase zwischen den Logon-Gruppen ablief.
Das Canary Skript wurde zum Ablauf gebracht, bevor sich ein Benutzer am System angemeldet hatte, und
die Zeit, die das Skript für einen Durchlauf benötigte (verstrichene Zeit), wird aufgezeichnet. Diese
verstrichene Zeit ist die Baseline, sie wird als Grundlinie für die Antwortrate in einer gegebenen
Serverkonfiguration erachtet. Mit dieser Methode wurde das Erreichen der maximalen Last festgelegt, wenn
die Gesamtzeit für einen Durchlauf des Canary Skripts um 10% höher als der Ausgangswert war. Die
Antwortzeit-Methode wird jedoch als genauer angesehen, da sie als Schlüsselparameter die momentane
Benutzer Erfahrung misst, auch den Einfluss der Logon-Phasen mit berücksichtigt und mehr Daten für eine
Entscheidungsfindung bereitstellt. Die »Canary« Skript-Methode kann aber in Konfigurationen effizienter
sein, die nur eine kleine Anzahl Benutzer betreiben und bei denen die Antwortzeit-Methode keine genügende
Menge an Antwortzeiten liefert.
Eine detaillierte Beschreibung findet man im »
« Dokument.
Ergebnisse von Fujitsu Siemens Computers und Microsoft
Um die Werte des Microsoft »Terminal Server Scaling and Capacity Planning« Tools und des Fujitsu
Siemens Computers Werkzeugs »T4US« zu vergleichen, wurden sowohl bei Microsoft als auch bei Fujitsu
Siemens Computers eine Reihe von Messungen aufgesetzt, bei denen die gleichen PRIMERGY Modelle
verwendet wurden:
Siemens Computers Werkzeugs »T4US« zu vergleichen, wurden sowohl bei Microsoft als auch bei Fujitsu
Siemens Computers eine Reihe von Messungen aufgesetzt, bei denen die gleichen PRIMERGY Modelle
verwendet wurden:
• Ein PRIMERGY RX300 S2 Server mit zwei Prozessoren mit 3.6 GHz, 1 MB SLC und 8 GB RAM.
Hyper-Threading war eingeschaltet und Microsoft Office 2003 wurde als Officeanwendung
verwendet. Als Betriebssystem wurde Windows 2003 Enterprise Edition in den 32-bit und 64-bit
Versionen verwendet.
verwendet. Als Betriebssystem wurde Windows 2003 Enterprise Edition in den 32-bit und 64-bit
Versionen verwendet.
• Ein PRIMERGY TX600 Server mit bis zu vier Prozessoren mit bis zu 2.8 GHz, 2 MB SLC und 8 GB
RAM. Hyper-Threading war eingeschaltet und Microsoft Office 2003 wurde als Officeanwendung
verwendet. Als Betriebssystem wurde die 32-bit Version von Windows 2003 Enterprise Edition
verwendet.
verwendet. Als Betriebssystem wurde die 32-bit Version von Windows 2003 Enterprise Edition
verwendet.
Microsoft arbeitet mit dem »Terminal Server Scaling and Capacity Planning« Tool, während Fujitsu Siemens
Computers das eigene »T4US« Tool einsetzt. Das Medium Lastprofil, das mit T4US verwendet wird, wird im
Kapitel »
Computers das eigene »T4US« Tool einsetzt. Das Medium Lastprofil, das mit T4US verwendet wird, wird im
Kapitel »
« im Detail erklärt. Das Benutzerprofil des »Terminal Server Scaling and Capacity
Planning« Tools von Microsoft wurde weiter
in diesem Abschnitt beschrieben.
© Fujitsu Siemens Computers, 2006
Seite 64 (68)