White Paper Sizing Guide Terminal Server Sizing Guide | Ausgabe: 3.3 Dezember 2006 |
Bei den Messungen mit variabler Benutzeranzahl wird der Terminal Server so weit belastet, bis sich die Antwortzeit der Applikation gegenüber einer Referenzzeit so weit verschlechtert, dass sie den vorgegebenen Regeln nicht mehr genügt. Hierbei werden die Performance Counter zwar mitgeschrieben und nach der Messung ausgewertet, jedoch einzig die Antwortzeit des Terminal Servers wird verwendet, um die Anzahl der Benutzer zu ermitteln, die zufriedenstellend mit dem Terminal Server arbeiten können.
Die Maßgabe für die Benutzerzufriedenheit kann im T4US Controller konfiguriert werden. Bei den diesem Terminal Server Sizing Guide zu Grunde liegenden Messungen darf sich jeder einzelne Messwert um 30% (Werte über 1500 ms) bzw. 100% (Werte bis 1500 ms) verschlechtern. Insgesamt müssen 90% der Messwerte innerhalb dieses Rahmens liegen, 10% Ausreißer werden toleriert. Jeder weitere Messwert, der die Grenze von 30% (bzw. 100%) Verschlechterung übersteigt, führt zur Beendigung der Messung. Die so erreichte Benutzeranzahl ist das Ergebnis der Messung und wird als »Score« bezeichnet.
Die Grafik veranschaulicht die Arbeitsweise des T4US Controllers bei der Auswertung der Messwerte. Die waagerechte Linie bei 1000 ms Antwortzeit ist die eingestellte Grenze, die 90% der Messwerte nicht überschreiten dürfen. Einige Ausreißer sind erlaubt, diese werden durch nachfolgende Werte innerhalb des erlaubten Bereichs kompensiert. Werden jedoch zu viele Ausreißer erkannt, gilt der Terminal Server als überlastet. Die Messung wird an dieser Stelle beendet, das Bild zeigt außerdem, wie sich die Messwerte weiter verschlechtern würden, wenn noch weitere Benutzer hinzugefügt
würden. In diesem Beispiel ist der Score »76 Benutzer«.
Um die Referenzzeit festzulegen, wurde auf fünf Lastgeneratoren je eine Instanz des betreffenden Lastprofils gestartet und dreimal erfolgreich durchlaufen. Die Referenzzeiten sind hauptsächlich von den Wartezeiten innerhalb der Skripte begrenzt und unterscheiden sich nur minimal von System zu System. Die Referenzzeiten selbst wurden nicht verwendet, um die Leistungsfähigkeit des betreffenden PRIMERGY Systems zu dokumentieren, sondern nur, um die Verlängerung der Antwortzeiten zu berechnen.
Im Vergleich zur Messung mit konstanter Benutzeranzahl, bei der eine Verschlechterung der Antwortzeiten von 10% erlaubt ist, arbeitet die Messung mit variabler Benutzeranzahl mit einem höheren Limit von 30%. Dies resultiert daraus, dass bei der Messung mit variabler Benutzeranzahl jeder einzelne Messwert dieses Limit einhalten muss und nicht nur der Durchschnitt.
Tuning
Auch wenn es von Microsoft und Citrix zahlreiche Artikel zur Optimierung von Betriebssystem- und Terminal Server gibt, so haben wir bei unseren Messungen doch gänzlich auf eine Optimierung verzichtet. Der Grund ist, dass viele dieser Einstellungen nur in bestimmten Umgebungen Sinn machen; in einem anderen Umfeld eingesetzt bewirken sie oft das Gegenteil. Da wir bei dieser Messreihe verschiedene PRIMERGY Systeme mit unterschiedlichen Systemkomponenten untersucht haben, wären die Ergebnisse nicht miteinander vergleichbar gewesen.
Die einzigen Einstellungen, die verändert werden um alle PRIMERGYs den gleichen Testbedingungen zu unterwerfen, sind:
•Das Pagefile des Betriebssystems wurde auf eine feste Größe von 4 GB eingestellt, um eine Fragmentierung zu vermeiden und damit für alle getesteten Server die gleichen Bedingungen vorliegen.
•Für Citrix musste die Grenze von 100 Benutzern pro Server, die durch das eingebaute Load Balancing vorgegeben wird (auch wenn die Terminal
Die bisher unter Windows 2000 Server notwendige Vergrößerung der Registry auf einem Terminal Server entfällt bei Windows Server 2003.
© Fujitsu Siemens Computers, 2006 | Seite 22 (68) |