Terminal Server Sizing Guide - Fujitsu

Terminal Server Sizing Guide 

Ausgabe 4.0 

Oktober 2009 

Seiten 46 

Abstract 

Terminal Server als eine Form des Server-based Computing hat sich in 

weiten Bereichen der IT Infrastruktur etabliert. Das vorliegende Papier 

beschäftigt sich mit der Frage, wie viele Benutzer eine als Terminal Server 

eingesetzte PRIMERGY mit adäquater Performance bedienen kann. Es 

soll helfen, für eine geforderte Leistungsklasse das passende PRIMERGY Modell zu 

finden. Nach einer allgemeinen Abhandlung über das Vermessen von Terminal Server 

wird das zum Dimensionieren der PRIMERGY Systeme benutzte Simulationswerkzeug 

(T4US) vorgestellt. Dann wird ausführlich darauf eingegangen, welche Komponenten 

welchen Einfluss auf die Leistungsfähigkeit eines Terminal Server Systems haben. 

Anschließend wird eine Einordnung älterer und aktueller PRIMERGY Systeme in 

Bezug auf ihre Leistungsfähigkeit als Terminal Server durchgeführt. Da eine Dimensionierung auch immer 

einen kundenspezifischen Aspekt beinhaltet, wird zusätzlich ein Überblick über nützliche Analysewerkzeuge 

und Engpassanalysen gegeben. Zum Abschluss werden Messmethoden anderer Hersteller skizziert. 

Inhalt 

Einführung ................................................................... 2 

PRIMERGY ............................................................... 2 

Server-based Computing .......................................... 2 

Windows Terminal Server ...................................... 2 

Lösungen ............................................................... 3 

Trends .................................................................... 3 

Dimensionierung .......................................................... 4 

Methoden .................................................................. 4 

Kenngröße »Benutzer« ............................................. 5 

Benutzersimulation ................................................... 5 

Interpretation ............................................................. 6 

Benchmark-Beschreibung ........................................... 7 

Simulationswerkzeug: T4US ..................................... 7 

Lastprofil ................................................................... 7 

Lastprofil V1 ........................................................... 8 

Lastprofil V2 ........................................................... 8 

Messmethode ........................................................... 9 

Messumgebung ......................................................... 10 

Ressourcenbedarf ..................................................... 12 

Betriebssystem ....................................................... 12 

IA64 ..................................................................... 12 

x64 ....................................................................... 12 

Limitierungen ....................................................... 13 

Auswirkungen ...................................................... 14 

Rechenleistung ....................................................... 15 

Prozessortyp ........................................................ 15 

Taktfrequenz ........................................................ 16 

Memory-Anbindung .............................................. 17 

Caches ................................................................. 18 

Hyper-Threading .................................................. 19 

Anzahl Kerne ........................................................ 20 

Arbeitsspeicher ....................................................... 21 

Disk-Subsystem ...................................................... 24 

Netzwerk ................................................................. 25 

Infrastruktur ............................................................. 26 

Überlastverhalten .................................................... 28 

Anzahl Prozesse .................................................. 28 

PRIMERGY Skalierung .............................................. 29 

Analysewerkzeuge ..................................................... 31 

Task-Manager ...................................................... 31 

Sysinternals Process Explorer ............................. 31 

Performance Monitor ............................................ 31 

Windows Performance Toolkit .............................. 32 

Citrix Resource Manager...................................... 34 

Microsoft Operations Manager (MOM) 2005 ........ 35 

Engpassanalyse ........................................................ 36 

Rechenleistung/System .......................................... 37 

Arbeitsspeicher ....................................................... 38 

Betriebssystemressourcen ...................................... 39 

Disk-Subsystem ...................................................... 40 

Netzwerk ................................................................. 41 

Terminal Server ...................................................... 42 

Applikationen .......................................................... 43 

Performance Monitor-Konfigurationsskript .............. 44 

Messwerkzeuge ......................................................... 45 

Literatur ...................................................................... 46 

Kontakt ....................................................................... 46

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009 

Einführung 

PRIMERGY 

»PRIMERGY« ist seit 1995 der Markenname für die sehr erfolgreiche Industrie-Standard-Server-Familie aus 

dem Hause Fujitsu Technology Solutions. Es handelt sich dabei um eine bei Fujitsu Technology Solutions 

entwickelte und produzierte Produktlinie mit Systemen für kleine Arbeitsgruppen bis hin zu Lösungen für 

Großunternehmen. Zu den PRIMERGY Modellen gehören neben wirtschaftlichen 1-Socket Systemen der 

Einstiegsklasse auch leistungsstarke Dual-Socket Systeme als Rack und Tower Modelle bis hin zu den 

Mehr-Sockel Systemen und Blade Servern. Als Herzstück werden Intel Prozessoren der obersten 

Leistungsklasse verwendet. Weitere detaillierte Informationen über die aktuellen Systeme findet man bei 

Fujitsu Technology Solutions im Internet. 

Server-based Computing 

Windows Terminal Server 

Terminal Server ist eine Form des Server-based Computing auf Basis von Microsoft Windows Server 

Betriebssystemen. 

Das klassische Server-based Computing ist 

eine Systemarchitektur, bei der Microsoft 

Windows Client-Anwendungen zu 100 

Prozent auf dem Server installiert und 

ausgeführt werden. Von dort erfolgt nicht nur 

deren Einsatz, sondern auch deren Wartung, 

Verwaltung und Support finden direkt auf 

dem Server statt. Lediglich die 

Benutzeroberfläche, d.h. die Bildschirm-, 

Maus- und Tastatur-Informationen werden 

zwischen Client und Server übertragen. Der 

Benutzer kann so von fast beliebigen Clients 

aus, auch nicht Windows basierten, über 

einen solchen Terminal Server sofort auf 

Windows Anwendungen zugreifen, ohne 

dass die jeweiligen Applikationen erst zum 

Client übertragen, dort gestartet, oder gar auf lokalen Massenspeichern vorgehalten werden müssten. Wird 

ein Client ausschließlich in diesem Server-based Szenario eingesetzt, so hat er hinsichtlich Speicher- und 

Plattenausstattung wesentlich geringere Anforderungen als ein traditioneller Client, man spricht daher auch 

von so genannten Thin-Clients. 

Vorteile des Server-based Computing sind die Kostenreduktion durch bessere Server-Auslastung sowie 

bessere Administration durch Zentralisierung von Anwendungen. 

Terminal 

Server 

Data 

Store 

Ein Terminal Server kann prinzipiell für alle 

Arten von Applikationen eingesetzt werden. Wo 

bislang kleine Rechner oder Terminals für 

einfache Dateneingabe bzw. -abfrage 

Verwendung fanden, können mit dem Terminal 

Server moderne Anwendungen in ein 

bestehendes Umfeld integriert werden. 

Eine Terminal Server Farm ist ein 

Zusammenschluß von Terminal Servern, die 

eine gemeinsame Verwaltungseinheit, Data 

Store genannt, besitzen. Diese werden 

gemeinsam administriert. Die Zuordnung von 

Benutzern zu Servern und Applikationen kann 

statisch erfolgen oder dynamisch nach 

Auslastung der Terminal Server (Load Balanced 

Server Farm). 

© Fujitsu Technology Solutions 2009 Seite 2 (46)


Lösungen 

Das Konzept des Server-based Computing hat seit 2000 unter dem Namen »Terminal Services« einen 

festen Platz in Server-Produkten der Microsoft Windows 2000 Server und Windows Server 2003 

Produktlinie. Selbst in dem Client-Betriebssystem ab Windows XP Professional steht in begrenztem Umfang 

der Terminal Service unter dem Namen »Remote Desktop« zur Verfügung. Von einem beliebigen Windows 

Client kann somit auf das entfernte System zugegriffen werden, wobei die Anwendungen komplett auf dem 

Remote-System ablaufen. Das unterliegende Protokoll wird als »Remote Desktop Protocol« (RDP) 

bezeichnet. Auch wenn seit dem aktuellen Betriebssystem Windows Server 2008 die Terminal-Dienste nicht 

mehr »Terminal Services« heißen, sondern in »Remote Desktop Services« (RDS) umbenannt wurden, wird 

in diesem Papier der Einfachheit halber weiterhin der Name »Terminal Services« verwandt. Die Remote 

Desktop Services unter Windows Server 2008 sind um Funktionen erweitert, die die Verwaltung von 

Terminal Server Anwendungen (RemoteApp), den Webzugriff (Remote Desktop Web Access) auf diese 

sowie den sicheren Zugang zu den Terminal-Diensten über das Internet (Remote Desktop Gateway) 

betreffen. 

Der größte Player im Terminal Server Umfeld ist das US-amerikanische Softwarehaus Citrix. Sein 

weiterentwickeltes Produkt »Citrix XenApp« (früher »Citrix Presentation Server«, davor »Citrix Metaframe«) 

dient der virtuellen Bereitstellung und dem Managen von Anwendungen insbesondere in großen Server- 

Umgebungen. Citrix XenApp basiert auf Microsoft Windows Terminal Services. Es bietet Erweiterungen und 

zusätzliche Funktionalitäten in den Bereichen der zentralen Verwaltung und Überwachung großer Server- 

Farmen, sowie Unterstützung in stark heterogenen IT-Umgebungen. Im Gegensatz zu Microsoft Terminal 

Server benutzt Citrix das eigenentwickelte, effiziente ICA-(Independent Computing Architecture) Protokoll 

zur Datenübertragung zwischen Client und Server. 

Trends 

Neben dem Konzept des Server-based Computing hat sich in den letzten Jahren das Konzept der 

Virtualisierung in den unterschiedlichsten Formen durchgesetzt. 

Server-Virtualisierung hat ähnlich wie Terminal Server Lösungen die Aufgabe, die Auslastung 

physikalischer Server zu erhöhen und Betriebskosten sowie Wartungs- und Administrationsaufwände zu 

verringern. 

Unter Applikations-Virtualisierung versteht man den Ansatz, Anwendungen von ihrer Umgebung zu 

isolieren, so dass Konflikte mit anderen Programmen oder dem Betriebssystem vermieden werden. Die 

Terminal Server Lösung von Citrix, »Citrix XenApp« realisiert Applikations-Virtualisierung durch die zwei 

Funktionalitäten: Application Streaming und Application Isolation. Das Application Streaming ermöglicht es, 

Anwendungen zum Client Device zu bringen und dort in einer geschützten und isolierten Umgebung 

ablaufen zu lassen. Die Applikations-Virtualisierungslösung von Microsoft findet sich in einem von Windows 

Terminal Server separaten Produkt »Microsoft Application Virtualization« (bekannt auch als App-V, früher 

SoftGrid). 

Eine der größten Barrieren bei der Einführung einer Terminal Server Lösung ist die Tatsache, dass allen 

Benutzern die gleiche Arbeitsplatzoberfläche bzw. die gleichen Anwendungen zur Verfügung gestellt 

wurden. Eine komplette Individualisierung, wie sie der Benutzer von seinem traditionellen Arbeitsplatz aus 

gewohnt ist, ist nicht möglich. Dieses wird bei der Desktop-Virtualisierung umgangen. Sie ist eine 

Zusammenführung der beiden Konzepte Virtualisierung und traditionelles Server-based Computing und 

findet sich im Konzept des von VMware zuerst eingeführten Begriffs des »Virtual Desktop Infrastructure« 

(VDI) wieder. 

In einer virtuellen Desktop-Umgebung sind die Desktops einzelner Benutzer in jeweils einer virtuellen 

Maschine eines Servers »gehostet«. Damit hat jeder Benutzer sein eigenes Desktop-System. Zugriff auf 

diesen virtuellen Arbeitsplatz kann z.B. über Protokolle wie RDP oder ICA erfolgen. Auch eine traditionelle 

Terminal Server Umgebung bietet die Möglichkeit, einem Benutzer in einer Session einen Desktop zur 

Verfügung zu stellen, allerdings entfällt die Möglichkeit der Personalisierung, wie sie bei einem traditionellen 

PC-Arbeitsplatz möglich wäre. Eine Diskussion welches Konzept – VDI oder Terminal Server – in welchem 

Umfeld mehr Vorteile bezüglich Kosten und Funktionalität bietet und sich damit durchsetzen wird, würde den 

Rahmen dieses Papiers sprengen, bleibt aber weiterhin spannend. 



Dimensionierung 

Methoden 

Bei der Skalierung – das ist der Prozess, das System an die benötigte Leistung anzupassen – werden zwei 

Methoden unterschieden: 

Scale-Up 

bezeichnet den Einsatz 

zunehmend größerer 

Server Systeme. 

Scale-Out 

bezeichnet den Einsatz von 

vielen kleineren Systemen, 

die sich die Arbeit teilen. 

Beim Scale-Up wird die Leistung eines Terminal Servers durch den Einsatz leistungsfähigerer Hardware, 

also insbesondere Rechenleistung und Arbeitsspeicher, erhöht. Es ist eine adäquate Skalierungsmethode, 

wenn eine überschaubare Anzahl an Benutzern zu bedienen ist. Diesem Skalierungsprozess sind Grenzen 

durch die maximale Leistungsfähigkeit des Server-Systems oder auch durch die Softwarearchitektur gesetzt. 

Insbesondere bei einem 32-bit Windows Betriebssystem ergeben sich Limitierungen im Speicherbereich, die 

dazu führen können, dass die Rechenleistung moderner Prozessoren nicht mehr voll ausgeschöpft werden 

kann. Genauer wird darauf im Kapitel Betriebssystem eingegangen. 

Beim Scale-Out werden viele Server zu einer Gruppe zusammengefasst. Man kann drei Varianten 

unterscheiden: 

1. Just a Bunch of Servers 

»Just a Bunch of Servers« ist eine lose Ansammlung von Servern, hier Terminal Servern, denen dedizierte 

Benutzergruppen oder Applikationen zugeordnet sind. Es findet jedoch unter den Terminal Servern kein 

Informationsaustausch und kein Lastenausgleich statt. Der Vorteil dieser Architektur ist die sehr einfache 

Erweiterbarkeit. Nachteilig ist, dass durch fehlenden Lastenausgleich Server-Leistung ungenutzt bleiben 

kann. Der administrative Aufwand ist recht hoch, da jedes System separat verwaltet werden muss. Dennoch 

wird diese Variante des Scale-Outs in der Praxis in kleineren Konfigurationen eingesetzt. 

2. Server-Farm 

Eine Terminal Server Farm ist ein Zusammenschluß von Terminal Servern, die eine gemeinsame 

Verwaltungseinheit besitzen. Die Zuordnung von Benutzern zu Servern und Applikationen erfolgt meist 

statisch. Vorteil gegenüber der »Just a Bunch of Servers« Variante ist die vereinfachte Administration der 

Server. Auch diese Variante des Scale-Outs wird in der Praxis sehr häufig eingesetzt. 

3. Load-balanced Server-Farm 

Bei einer »load-balanced Server-Farm« werden die 

einzelnen Terminal Server zu einer logischen Einheit 

zusammengefasst. Wird von einem Client eine Session 

initiiert, so wird diese von einem Load Balancer nach 

bestimmten Mechanismen an den Server mit der 

momentan geringsten Auslastung delegiert. Neben der 

besseren Auslastung der Terminal Server bietet das 

Load Balancing auch eine gewisse Redundanz. 

Aktuelle Terminal Server Softwarelösungen, sowohl 

von Microsoft als auch Citrix, bieten umfangreiche 

Möglichkeiten des Load Balancing. 



Load Balancer 

Session 

List 

Im Folgenden beschäftigen wir uns mit einem Scale-Up Scenario, d.h. der Dimensionierung eines einzelnen 

Terminal Servers. 



Kenngröße »Benutzer« 

Vor jeder Implementierung eines Applikations-Servers steht immer die gleiche Frage: Welches ist die 

passende Hardware für die geforderte Aufgabe? Natürlich möchte man dabei ein möglichst optimales 

System, welches weder für die Anforderungen zu klein noch (aus Kostengründen) total überdimensioniert ist. 

Die Frage ist also: Wie findet man ein wohl dimensioniertes System? 

Die einzige meist vorliegende Kenngröße ist die Anzahl Benutzer, die mit dem System arbeiten sollen. Die 

typische Frage, die also zumeist auftritt, ist: »Welches PRIMERGY Modell benötigt man für einen Terminal 

Server zur Unterstützung einer bestimmten Anzahl von Benutzern?«. Optimalerweise würde man als Antwort 

eine handliche Tabelle erwarten, aus der anhand der Benutzerzahl in der einen Spalte unmittelbar aus der 

zweiten Spalte das ideale PRIMERGY System abgelesen werden kann. Leider gibt es eine solche Tabelle 

nicht – auch wenn mancher Mitbewerber dies dem Kunden mit bunten Web-Seiten suggeriert. Die Antwort 

auf die scheinbar so einfache Frage ist doch wesentlich komplexer, denn sie enthält eine große Unbekannte, 

und die ist der Benutzer. 

Ein Benutzer ist, auch wenn dies viele vielleicht wünschen, keine standardisierte und berechenbare Größe, 

sondern ein Individuum mit unterschiedlichem Arbeitstempo und Arbeitsverhalten. Das Arbeitstempo z.B. 

bestimmt mit welcher Häufigkeit Eingaben gemacht werden und hat damit direkten Einfluss auf die 

Belastung des Terminal Server Systems. Hinzu kommen unterschiedliche Arbeitsaufgaben, die in 

unterschiedlichen Anforderungen an ein Computersystem resultieren. Ein Benutzer, dessen Aufgabe aus 

Abfragen an ein Lagerhaltungssystem besteht, wird eine andere Last auf einem Computersystem erzeugen, 

als ein Benutzer, dessen Aufgabe es ist, eine grafische Werbebroschüre zu entwerfen. Nicht zu 

vernachlässigen ist der mit der Zeit steigende Ressourcenverbrauch der Applikationen durch deren 

Weiterentwicklung, z.B. im Bereich 3D-Grafik oder Multimedia/Videoanwendungen. 

Die folgende Tabelle zeigt eine Einteilung der Benutzer in Gruppen nach ihrem Benutzerverhalten und 

Belastungsprofil. 

Heavy 

Medium 

Light 

Knowledge Worker 

Process Worker 

Data Entry Worker 

nutzt gleichzeitig mehrere verschiedene Anwendungen 

gibt Daten mäßig schnell ein 

führt komplexere Operationen aus 

arbeitet zu einer Zeit intensiv mit einer Anwendung 

gibt schnell viele Daten ein 

arbeitet kontinuierlich 

arbeitet zu einer Zeit nur mit einer Anwendung 

gibt wenig Daten ein 

längere Pausen zwischen den Eingaben 

Wie im Kapitel Lastprofil noch erläutert wird, wurde bei den Messungen für das vorliegende Dokument das 

Verhalten eines Medium Benutzers angenommen. 

Benutzersimulation 

Bei Leistungsmessungen werden generell keine realen Benutzer verwendet, sondern die Benutzer werden 

mit Hilfe von Computern, so genannten Lastgeneratoren, und einer speziellen Software simuliert. Dabei wird 

von einem physikalischen Lastgenerator zumeist eine Vielzahl von logischen Benutzern simuliert, so dass je 

nach Lastgenerator einige zig oder hundert Benutzer simuliert werden können. Die folgende Abbildung zeigt 

eine typische Simulationsumgebung. 

Simulations- 

Netzwerk 

… 

SUT- 

Netzwerk 

Controller 

Lastgeneratoren 

System 

under Test 

(SUT) 

Infrastruktur- 




Der Controller ist die zentrale Steuerkonsole, die die Simulation steuert und überwacht. Über ein 

Simulations-Netzwerk ist dieser mit den Lastgeneratoren verbunden. Jeder Lastgenerator kann eine Vielzahl 

von Benutzern simulieren. Die Lastgeneratoren erreichen das Testsystem (System under Test (SUT)) über 

ein zweites Netzwerk, in dem sich auch noch ein Infrastruktur-Server befindet. Dieser liefert dem SUT die 

notwendigen Dienste, aber er wird selbst nicht vermessen. 

Unterschiedliche Benutzergruppen, wie oben diskutiert, werden von Lastsimulatoren zumeist durch 

verschiedene Lastprofile, im Terminal Server Umfeld auch Skript genannt, berücksichtigt. 

Bei der Benutzersimulation unterscheidet man die Begriffe »Lastgenerator«, »Client« und »Benutzer«. Im 

weiteren Verlauf wird als »Lastgenerator« die Hardware bezeichnet. Ein »Client« ist der Terminal Server 

Client, von dem einer oder mehrere auf dem Lastgenerator ausgeführt werden. Ein simulierter »Benutzer« 

arbeitet innerhalb einer Terminal Server Sitzung. 

Interpretation 

Anders als bei anderen Benchmarks, wo es vom Hersteller der Applikation oder einem unabhängigen 

Gremium einen Benchmark und ein entsprechendes Reglement zur Durchführung gibt, wie z.B. bei Microsoft 

Exchange Server, SAP R/3, SPECweb oder TPC, gibt es für Terminal Server bis heute keinen 

standardisierten und akzeptierten Benchmark. Es existieren zwar verschiedene Produkte verschiedener 

Hersteller zur Benutzersimulation, aber es gibt kein standardisiertes Werkzeug, mit dem sowohl Microsoft als 

auch Citrix Terminal Server vermessen und verglichen werden können. 

Ergebnisse solcher Performance-Messungen verschiedener Hersteller oder Benchmark-Labore sind unter 

diesen Bedingungen natürlich nicht untereinander vergleichbar. Nur Messungen, die in gleicher Umgebung 

und mit vergleichbarem Lastprofil durchgeführt wurden, können auch sinnvoll verglichen werden. 

Weiterhin ist zu beachten, dass es sich bei den Terminal Server Sizing Messungen um Auswertungen in 

einer vereinfachten, idealisierten und standardisierten Umgebung handelt, um vergleichbare Bedingungen 

für alle Systeme zu schaffen. Zusätzliche Komponenten und Programme sind nicht installiert, und der 

Terminal Server wird bis an seine Leistungsgrenze belastet. In der Realität wird man Zusatzsoftware wie 

zum Beispiel einen Virenscanner installiert haben, oder man betreibt weitere Add-Ons der Terminal Server 

Software. Auch werden Terminal Server im Produktivbetrieb nicht bis an ihre Leistungsgrenze belastet. 

Vor diesem Hintergrund kann man also sagen: 

Obgleich die Einheit vieler Performance-Messungen »Anzahl Benutzer pro Server« ist, sollte man nur 

Ergebnisse von Performance-Messungen im gleichen Umfeld miteinander vergleichen. Sie sollten in erster 

Linie auch nur relativ betrachtet werden, also beispielsweise »ein System A ist doppelt so 

leistungsfähig wie ein System B« oder »die Verdopplung des Arbeitsspeichers resultiert in x% 

Leistungssteigerung«. Denn wie bereits im Kapitel Kenngröße »Benutzer« erläutert, ist ein Benutzer 

schwer zu quantifizieren, und ein synthetischer Benutzer muss nicht in allen Fällen mit einem realen 

Benutzer korrelieren. 



Benchmark-Beschreibung 

Simulationswerkzeug: T4US 

Fujitsu Technology Solutions hat einen eigenen Lastsimulator, T4US, entwickelt, der unabhängig von dem 

verwendeten Terminal Server und ohne Einflüsse auf das zu testende System beliebige Benutzerprofile 

simulieren kann. 

Benutzeraktivitäten wie Tastatur- und Mauseingaben 

sowie Bildschirmausgaben können mit Hilfe des Aufzeichnungswerkzeugs 

T4US-Record in Echtzeit aufgezeichnet 

und in einem T4US-Skript gespeichert 

werden. T4US-Skripte werden während der Messung 

als Lastprofil verwendet. 

Benutzer bei 

der Arbeit 

T4US 

Record 

T4US 

Skript 

Der Lastsimulator von T4US besteht aus drei Komponenten. 

T4US-Control steuert und 

überwacht den gesamten 

Simulationslauf zentral und 

ermittelt Messwerte bereits 

während der Messung. Auf 

jedem der Lastgeneratoren 

laufen mehrere Instanzen 

des T4US-Playback. Jedes 

T4US-Playback »füttert« 

einen Terminal Server 

Client in Echtzeit mit Tastatur- 

und Mauseingaben 

Controller 

Lastgenerator 

anhand der mit T4US- 

T4US 

T4US 

Record aufgezeichneten 

T4US 

Agent 

Play 


Control 


Skripte und überwacht die 

TS Client 

Bildschirminhalte des 

Terminal Server Clients. 

Durch hoch auflösende Timer wird so die Antwortzeit des Terminal Servers ermittelt. Auf jedem der Lastgeneratoren 

läuft ein T4US-Agent, der für die Kommunikation mit dem Controller zuständig ist, die Instanzen 

von T4US-Playback steuert und überwacht und die ermittelten Antwortzeiten zum Controller überträgt. 

Bei der Messung wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, kontinuierlich erhöht. 

Die Antwortzeiten des Terminal Servers werden vom T4US-Controller überwacht und mit gespeicherten 

Referenzwerten, die in einer vorhergehenden Referenzmessung mit nur wenigen Benutzern ermittelt worden 

sind, verglichen. Wenn sich die Antwortzeit der Anwendung so weit verschlechtert, dass sie den vorgegebenen 

Regeln nicht mehr genügt, wird die Messung beendet und man erhält die Benutzeranzahl als Resultat 

der Messung 

T4US 

Play 

T4US 

Play 

… 

System under Test (SUT) 

TS Client 

TS Client 

SUT 

… 

Lastprofil 

Wie im Kapitel Kenngröße »Benutzer« schon erläutert wurde, hängt die Belastung eines Terminal Servers 

stark vom Benutzer ab. Das Benutzerverhalten spiegelt sich bei einer Simulation im Lastprofil wider. Die hier 

beschriebenen Lastprofile simulieren das Verhalten eines »Medium User«, der zu einer Zeit intensiv mit 

einer Anwendung arbeitet und kontinuierlich, schnell viele Daten eingibt. 

Der größte Teil der Messungen für den »Sizing Guide« wurde mit dem Lastprofil V1 durchgeführt. Allerdings 

stellte sich heraus, dass durch verbesserte Leistung der zu vermessende Systeme (neue 

Prozessorgenerationen) der Benchmark mit diesem Lastprofil in eine Größenordnung kam, bei der die 

gemessene Benutzeranzahl durch die Anzahl Ab- und Anmeldevorgänge, also daraus resultierende 

Restriktionen im Betriebssystem, erreicht wurde und nicht mehr durch die Prozessorleistung des Systems. 

Das bedeutete, der Benchmark erreichte seine Grenzwerte schon ohne den Prozessor auszulasten. 

Verbesserte Prozessorleistung und damit auch Systemleistung konnten so nicht mehr gemessen werden. 



Deshalb wurde ein neues Lastprofil V2 definiert. Die mit dem Lastprofil V2 erreichten maximalen 

Benutzerzahlen pro System sind natürlich nicht direkt vergleichbar mit den Benutzerzahlen des Lastprofils 

V1. Im Kapitel PRIMERGY Skalierung werden daher die Messergebnisse in Relation zueinander und nicht 

mehr absolut angegeben. 

Lastprofil V1 

Im Lastprofil V1 dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit 

einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute. 

Des Weiteren beinhaltet das Lastprofil: 

Jeder Benutzer arbeitet unter einem eigenen Benutzerkonto. 

Die erste Anmeldung (Login) des Benutzers und der erste Start der Anwendung liegen außerhalb der 

Messstrecke. Jedoch meldet sich der Benutzer nach einmal getaner Arbeit am Terminal Server ab und 

für einen neuen Durchlauf wieder an. Da die Benutzer versetzt gestartet werden, ergibt sich so während 

der gesamten Messdauer ein kontinuierliches An- und Abmelden. 

Jeder Terminal Server Client (Benutzer) startet die Applikation aus seinem Desktop heraus, die 

Applikation wird bei jedem Skriptdurchlauf gestartet und beendet. 

Jeder Benutzer hat sein eigenes Verzeichnis, in dem die im Text verwendeten Bilder hinterlegt sind. So 

wird verhindert, dass alle Benutzer die gleichen Bilder-Dateien laden und sich diese nach kurzer Zeit alle 

im Server File Cache befinden. Jeder Benutzer schreibt bei jedem Skriptdurchlauf ein neues Dokument 

mit eindeutigem Namen. Nach erfolgreicher Erstellung wird das Dokument auf die Festplatte des 

Terminal Servers in ein benutzereigenes Verzeichnis gespeichert. 

Die durchschnittliche Eingabegeschwindigkeit liegt bei etwa 4 Zeichen bzw. Cursor-Bewegungen pro 

Sekunde. Allerdings finden nicht während des gesamten Durchlaufes Eingaben statt, denn es sind 

diverse, unterschiedlich lange Denkzeiten im Skript eingestreut, wie es einem natürlichen Arbeiten nahe 

kommt. 

Die Bildschirmauflösung ist 1024x768, die Farbtiefe ist 16-bit. 

Ein Durchlauf des Skripts inklusive Wartezeiten dauert ca. 16 Minuten. 

Lastprofil V2 

Das neue Lastprofil V2 zeichnet sich dadurch aus, dass ein zu simulierender Benutzer mit verschiedenen 

Microsoft Office Anwendungen nacheinander arbeitet. Neben der Erstellung eines Microsoft Word 

Dokumentes wird auch eine PowerPoint-Präsentation kreiert. Ebenso werden Berechnungen auf einem neu 

angelegten Excel-Arbeitsblatt durchgeführt. Die Anzahl der An- und Abmeldevorgänge ist im Vergleich zum 

Lastprofil V1 reduziert. Im Schnitt meldet sich nur jeder sechste Benutzer zyklisch am Terminal Server ab 

und wieder an. Ebenso druckt durchschnittlich jeder sechste Benutzer ein Word-Dokument aus. Zusätzliche 

CPU-Last wird durch Verpacken und Entpacken von Dateien im Speicher erreicht. Die Tippgeschwindigkeit 

des simulierten Benutzers beträgt zwischen 330 und 440 Anschlägen pro Minute. 

Die weiteren Rahmenbedingungen gelten wie beim Lastprofil V1: 

Jeder Benutzer arbeitet unter einem eigenen Benutzerkonto. 

Jeder Terminal Server Client (Benutzer) startet die Applikation aus seinem Desktop heraus, die 

Applikation wird bei jedem Skriptdurchlauf gestartet und beendet. 

Jeder Benutzer hat sein eigenes Verzeichnis, in dem die im Text verwendeten Bilder hinterlegt sind. So 

wird verhindert, dass alle Benutzer die gleichen Bilder-Dateien laden und sich diese nach kurzer Zeit alle 

im Server File Cache befinden. Jeder Benutzer schreibt bei jedem Skriptdurchlauf ein neues Dokument 

mit eindeutigem Namen. Nach erfolgreicher Erstellung wird das Dokument auf die Festplatte des 

Terminal Servers in ein benutzereigenes Verzeichnis gespeichert. 

Die Bildschirmauflösung ist 1024x768, die Farbtiefe ist 16-bit. 



Messmethode 

Zu einer Leistungsmessung gehört neben einem Simulationswerkzeug und einem möglichst realistischen 

Lastprofil ein Regelwerk, nach dem die einzelnen Messungen durchgeführt und bewertet werden. Im 

Folgenden wird das Regelwerk beschrieben, nach der die Messungen für diesen Sizing Guide durchgeführt 

wurden. 

Bei der Messung mit variabler 

Benutzeranzahl wird die Anzahl der 

Benutzer, die mit dem Terminal 

Server arbeiten, nach einer 

voreingestellten Regel kontinuierlich 

erhöht, bis der Terminal Server 

überlastet ist. Dabei wird eine 

Überlastung des Servers durch die 

gemessenen Antwortzeiten im 

Vergleich zu vorher festgelegten 

Referenzzeiten definiert. Insgesamt 

müssen 90% der Messwerte 

innerhalb eines festgesetzten 

Rahmens liegen, 10% Ausreißer 

werden toleriert. Die so erreichte 

Benutzeranzahl ist das Ergebnis der Messung und wird als »Score« bezeichnet. 

Die Referenzzeiten werden vorher aus den durchschnittlichen Antwortzeiten bei geringer Belastung (nur 

wenige simulierte Benutzer) ermittelt. Sie sind hauptsächlich von den Wartezeiten innerhalb der Skripte 

begrenzt und unterscheiden sich nur minimal von System zu System. 

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. In diesem 

Beispiel ist der Score »76 Benutzer«. 

Das Bild zeigt außerdem, wie sich 

die Messwerte weiter verschlechtern würden, wenn noch weitere Benutzer hinzugefügt würden. Rechts von 

der senkrechten Markierung verlängern sich die Antwortzeiten für alle Benutzer erheblich. 

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 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 entsprechend des verwendeten 

Hauptspeichers 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 Server Farm aus nur einem Terminal Server besteht) 

aufgehoben werden. 



Messumgebung 

Untersucht wurden alle aktuellen PRIMERGY Modelle, die für den Einsatz als typischer Terminal Server 

geeignet sind, in der folgenden Messumgebung: 

Controller 

für die 

Simulation 

Lastgeneratoren 

System 

under test 

(SUT) 

Infrastruktur- 


Simulationsnetzwerk 

SUT- 

Netzwerk 

switched 

100 Mbit 

switched 

100 Mbit 

PRIMERGY C200 

T4US-Control 

ca. 40 PRIMERGY Dual Server 

Windows Server 2003 

TS-Client 

T4US-Agent, T4US-Playback 

Jeder simuliert bis zu 12 Benutzer 

PRIMERGY 



Enterprise Edition 

PRIMERGY C200 


Active Directory 

Terminal Server 

Licensing Service 

Controller (T4US-Control): 

Auf dem Controller kam Windows Server 2003 Standard Edition zum Einsatz. 

Lastgeneratoren: 

20 - 40 Lastgeneratoren (PRIMERGY Dual Server) 

Die Lastsimulatoren liefen unter dem Betriebssystem Windows Server 2003 Standard Edition SP1. Die 

Messungen mit Lastprofil V2 wurden mit SP2 durchgeführt. 

Clients: 

Für den Zugriff auf den Terminal Server über das ICA-Protokoll wurde der Citrix Terminal Server Client 

(Programm Neighborhood mit 32-bit ICA-Client) verwendet (entweder Version 7.00.17534 aus »Citrix 

MetaFrame XP Presentation Server« Feature Release 3 oder Version 9.00.32649 aus »Citrix 

Presentation Server 4.0«). 

Der RDP-Client (»Remote Desktop«) von Microsoft ermöglicht den Zugriff auf einen Terminal Server 

über das RDP-Protokoll. In Windows Server 2003 Standard Edition ist die Version 5.2.3790.1830 des 

RDP-Clients enthalten, der das RDP-Protokoll V5.2 unterstützt. Die Messungen mit dem Lastprofil V2 

wurden mit dem RDP-Protokoll V6.0.6000.16459 durchgeführt. 

Netzwerk: 

Die Anbindung der Lastsimulatoren an das SUT-Netzwerk erfolgte über ein 100 MBit-Ethernet-Netzwerk, 

wobei der Terminal Server über den Gigabit-Uplink angeschlossen war. Das Netzwerkprotokoll war 

TCP/IP. 

Terminal Server (System under Test): 

Die vermessenen PRIMERGY Server (System under Test) waren jeweils mit Windows Server 2003 

Enterprise Edition ausgestattet. Die Terminal Services waren im Application Server Modus aktiviert. Die 

Messungen mit dem Lastprofil V2 wurden unter Windows Server 2008 durchgeführt. 

Bei den Messungen, bei denen ein Citrix Terminal Server vermessen wurde, war entweder Citrix 

MetaFrame Enterprise Edition mit Service Pack 3 und Feature Release 3 oder Citrix Presentation Server 

installiert. Die Terminal Server Farm bestand nur aus einem Terminal Server. Der Data Store befand 

sich lokal auf der Systemplatte des zu vermessenden Systems und war als Microsoft Access Datenbank 

realisiert. 

Auch die Dateien der Benutzer, die während der Messung gelesen und geschrieben wurden, lagen lokal 

auf dem Terminal Server. 

Die Benutzerprofile wurden standardmäßig auf dem Terminal Server gespeichert. 



Infrastruktur-Server: 

Der Infrastruktur-Server stellt dem System under Test notwendige Dienste zur Verfügung, er selbst 

wurde nicht vermessen. Der Server wurde so dimensioniert, dass er keinen Engpass darstellt. 

Die Benutzerkonten der simulierten Benutzer wurden auf dem Active Directory Domain Controller 

angelegt. Ein Login fand immer gegen das Active Directory statt. 

Das Active Directory System dient gleichzeitig als DNS Server und beherbergt den Terminal Server 

Licensing Service. 

Der Infrastruktur-Server lief unter dem Betriebssystem Windows Server 2003 Standard Edition SP1. 



Ressourcenbedarf 

Im Folgenden wollen wir diskutieren und anhand von Messergebnissen untermauern, welche Komponenten 

welchen Einfluss auf die Leistungsfähigkeit eines Terminal Server Systems haben. Dabei wird neben 

Aspekten des Betriebssystems auf die Performance-relevanten Faktoren eines Server-Systems wie 

Rechenleistung, Arbeitsspeicher, Disk-Subsystem und Netzwerk eingegangen. Im Anschluss daran wird das 

Umfeld, in dem ein Terminal Servers betrieben wird, betrachtet und auf Komponenten der Infrastruktur 

hingewiesen, die das Performance-Verhalten beeinflussen. Zum Abschluss wird das Verhalten eines 

Terminal Servers in beobachteten Überlastsituationen erläutert. 

Betriebssystem 

Microsoft Windows Server Betriebssysteme existieren bis Windows Server 2008 in zwei Varianten, der 32- 

bit- und der 64-bit-Variante. Auch wenn es zukünftige Betriebssysteme – ab Windows Server 2008 R2 – nur 

in der 64-bit-Variante geben wird, soll hier noch auf die Unterschiede und die damit möglichen Performance- 

Einbußen bei Terminal Server eingegangen werden. 

Voraussetzung für ein 64-bit-Betriebssystem ist eine 64-bit-Hardware-Plattform. Hier unterscheiden wir 

aktuell Intel Itanium (IA64) und x64. 

IA64 

Prozessoren der IA64 Plattform sind nicht Code-kompatibel zu 32-bit-Anwendungen (x86); das hat zur 

Konsequenz, dass x86-Anwendungen auf Itanium Systemen lediglich emuliert werden, was jedoch einen 

entsprechenden Performance-Verlust durch die Emulationsschichten bedeutet. Einen Terminal Server auf 

einer IA64 Architektur zu betreiben ist also nicht sinnvoll, da alle 32-bit-Anwendungen (z.B. Microsoft Office 

2007) durch die Emulation sehr langsam laufen würden. Daher gibt es aktuell für Itanium-basierte Systeme 

weder Citrix Terminal Server Lösungen noch kann unter Windows Server 2008 das Feature Terminal Server 

konfiguriert werden. 

x64 

Mit x64 werden die Architekturen bezeichnet, die 100% kompatibel zur x86-Architektur sind und nur 

Erweiterungen für 64-bit bieten. Hierzu zählen der AMD Opteron mit der AMD64-Achitektur und die Intel 

Pentium und Xeon Prozessoren der neuesten Generation mit EM64T (jetzt Intel 64)-Architektur. 

Der Vorteil der x64 Plattform ist, dass 32-bit-Anwendungen, wie z.B. Microsoft Office direkt unter dem x64- 

Betriebssystem ausgeführt werden können. Das 64-bit Windows stellt das WoW64 (»Windows on 

Windows64«) Subsystem bereit, um einen reibungslosen Betrieb der 32-bit-Applikationen zu ermöglichen. 

Im WoW64 werden Zugriffe auf den Speicher, auf die Registry und auf das Dateisystem isoliert. Allerdings 

gilt für viele systemnahe Anwendungen und alle Anwendungen, die Treiberkomponenten enthalten, sie 

müssen speziell für x64-Systeme angepasst werden, da sie im 32-bit-Modus nicht ablauffähig sind. Beispiele 

für Anwendungen, die speziell für 64-bit angepasst wurden sind Microsoft SQL Server oder Microsoft 

Exchange Server und die Terminal Server Produkte von Citrix. 16-bit-Anwendungen für DOS oder Windows 

sind generell nicht mehr ablauffähig, dies ist insbesondere ein Problem für Anwendungen mit einem 16-bit- 

Installer. 

Nachfolgende Tabelle gibt einen Überblick über relevante Systemplattformen und Windows Produkte und 

deren Anforderungen an Gerätetreiber und Anwendungen. 

Server-Plattform x86 x64 x64 

Windows Produkt 

Windows Server 2003 R2 / 


Standard Edition 


Datacenter Edition 



Standard Edition 


Datacenter Edition 



Standard x64 Edition 

Enterprise x64 Edition 

Datacenter x64 Edition 

Betriebssystem 32-bit 32-bit 64-bit 

Gerätetreiber 32-bit 32-bit 64-bit 

Anwendungen 32-bit 32-bit 32-bit und 64-bit 



Limitierungen 

Der wesentliche Unterschied zwischen 32-bit- und 64-bit-Architektur liegt in der Größe des adressierbaren 

Speichers. Mit einer 32-bit-Architektur sind durch die Wortbreite des Prozessors maximal 2 32 Byte =4 GByte 

adressierbar, mit einer 64-bit-Architektur sind es bis zu 2 64 Bytes = 16 Exabyte (EB). Die nachfolgende 

Tabelle gibt einen Überblick über die Limitierungen der verschiedenen 32-bit und 64-bit Windows Produkte, 

die für Terminal Server sinnvoll eingesetzt werden können. 

Windows Produkt 

(WS = Windows Server) 

WS 2003 R2 / WS 2008 

Standard 

Edition 

Enterprise 

Edition 

WS 2003 R2 x64 / WS 2008 x64 

Standard 

Edition 

Enterprise 

Edition 

Anzahl Prozessoren 1 – 4 1 – 8 1 – 4 1 – 8 

Max. RAM 

gesamter virtueller 

Adressraum 

Virtueller Adressraum 

eines 32-bit-Prozesses 

Virtueller Adressraum 

eines 64-bit-Prozesses 

4 GB 

64 GB 

(mit PAE) 

32 GB 2 TB 

4 GB 16 TB 

2 GB 2 GB 

3 GB wenn mit 

/3GB Switch gebootet 

4 GB wenn mit 

/LARGEADDRESSAWARE 

übersetzt wurde 

- 8 TB 

Paged Pool 470 MB / WS 2008 dynamisch 128 GB 

Non-Paged Pool 256 MB / WS 2008 dynamisch 128 GB 

System Page Table 

Entries 

ca. 900 MB / WS 2008 dynamisch 128 GB 

System Cache 1 GB / WS 2008 dynamisch 1 TB 

Bei dem 32-bit Windows ist der virtuelle Adressraum von 4 GB standardmäßig in 2 GB für das 

Betriebssystem und 2 GB für die Anwendungen unterteilt. In den 2 GB, die vom Betriebssystem verwendet 

werden, werden alle Datenstrukturen und Informationen des Kerns gehalten. Hier sind drei besondere 

Datenbereiche zu nennen: die Paged Pool Area, die System Page Table Entries (PTE) Area und der System 

File Cache. Speicher aus der Paged Pool Area wird von Kernel-Mode Komponenten angefordert, während 

die PTE Area für Kernel Stack Allocations verwendet wird. Im System File Cache werden Speicherabbilder 

von geöffneten Dateien gehalten. Diese Bereiche teilen sich einen Speicherbereich und die Grenze 

zwischen ihnen wird unter Windows Server 2003 beim Systemstart fest eingestellt. Wenn dem 

Betriebssystem während der Laufzeit in einem Bereich der Speicher ausgeht, kann dies nicht aus den 

anderen Bereichen ausgeglichen werden. Die Folge ist, dass keine neuen Benutzer mehr angemeldet 

werden können oder dass unerwartete Fehler auftreten. In 32-bit Windows Server 2008 wird der Kernel 

Address Space dynamisch verwaltet und die Speicherbereiche für Paged Pool, System Cache etc. können 

entsprechend der Arbeitslast wachsen oder schrumpfen. Begrenzt werden die Bereiche aber durch den 

aktuell verfügbaren virtuellen Adressraum des Kernels. 

PAE (Physical Address Extension) ist eine technische Erweiterung für x86 kompatible CPUs (ab Intel 

Pentium und AMD Athlon) die es ermöglicht bis zu 2 36 Bytes = 64 GByte Speicher zu adressieren. Dies ist 

möglich, da diese Prozessoren einen 36 Bit breiten Adressbus besitzen. Spezielle Erweiterungen in der 

»Paging«-Einheit des Prozessors sorgen dafür, dass 36-bittige physikalische Adressen generiert werden. 

Um PAE nutzen zu können, muss es vom Betriebssystem unterstützt werden. 

64-bit Windows nutzt vom theoretischen Wert von 16 EB adressierbaren Speichers 16 TB als virtuellen 

Adressraum. Windows teilt diesen (zumindest aus heutiger Sicht) gigantischen Adressraum in verschiedene 

Bereiche auf, so dass für den Kernel und jeden 64-bit-Prozess jeweils ein Adressraum von 8 TB zur 

Verfügung steht. Für 32-bit-Anwendungen, die im so genannten Kompatibilitätsmodus laufen, steht pro 

Anwendung ein Adressbereich von 4 GB zur Verfügung, aber auch das ist mehr als bei einem reinen 32-bit- 

Betriebssystem, bei dem es maximal 3 GB sind. 



Auswirkungen 

Wenn ausreichend Hardware-Ressourcen zur Verfügung 

stehen, also weder die CPU noch der Arbeitsspeicher der 

begrenzende Faktor ist, dann können auf einem 64-bit- 

System wesentlich mehr Benutzer betrieben werden als 

auf einem 32-bit-System. Der Grund hierfür liegt in der 

Betriebssystemarchitektur, genauer gesagt, bei den 

Kernel-Ressourcen. Das 32-bit-Betriebssystem hat einen 

Adressraum von 2 GB zur Verfügung, um seine Daten, 

unter anderem Kernel-Tabellen und System Cache, zu 

speichern. Bei hinreichender Rechenleistung erreicht die 

Benutzeranzahl eine Größenordnung, die für ein 32-bit- 

Betriebssystem zu hoch ist. Die Kernel-Tabellen sind 

vollständig belegt, was in Paging-Aktivitäten resultiert, 

obwohl noch Hauptspeicher frei ist. Weiterhin ist auch der 

System Cache überlastet und kann nicht weiter vergrößert 

werden, was zu einer schlechten Trefferrate im Cache 

(Light Lastprofil, Microsoft Office 2003, 

führt. Hierdurch steigen ebenfalls die Plattenzugriffe 

Microsoft Terminal Services) 

sprunghaft an. Sobald auf die Festplatte statt auf den 

Arbeitsspeicher zugegriffen werden muss, macht sich das sofort in einer Verschlechterung der Antwortzeiten 

bemerkbar. Würde man den Terminal Server über diese Engpasssituation hinaus weiter belasten, so würden 

die Applikationen auf Fehler laufen oder Benutzer könnten sich beim Terminal Server gar nicht mehr 

anmelden. 

In welchem Szenario ein 32-bit-Betriebssystem oder ein 64-bit-Betriebssystem Vorteile bringt, lässt sich gut 

an Hand einer durchgeführten Messreihe erläutern. Das gleiche PRIMERGY System mit jeweils 

ausreichender Rechenleistung wurde mit 4, 8, 16 und 32 GB RAM ausgestattet und die maximale Anzahl 

Light User ermittelt. Bei den Messungen mit 4 GB Hauptspeicher ist sowohl unter dem 32-bit-Betriebssystem 

als auch unter dem 64-bit-Betriebssystem der Hauptspeicher der limitierende Faktor, was in Paging- 

Aktivitäten resultiert. Die Messungen unter 64-bit ergeben sogar ein leicht schlechteres Ergebnis. Erklärbar 

ist das dadurch, dass 64-bit-Anwendungen in der Regel mehr Arbeitsspeicher benötigen als die 32-bit- 

Versionen, denn alle Adresszeiger sind bei 64-bit doppelt so breit (siehe Kapitel Arbeitsspeicher). 

Bei einer Vergrößerung des Speichers auf 

8 GB können mehr Benutzer bedient werden, 

dieser Speicherausbau ist hier die optimale 

Konfiguration für das 32-bit-System. 

Eine weitere Speicheraufrüstung auf 16 GB 

bzw. 32 GB ist bei diesen Messungen unter 

dem 32-bit-Betriebssystem nicht von Vorteil. 

Wie schon oben erläutert, führen die begrenzten 

Kernel-Ressourcen dazu, dass nicht mehr 

Benutzer unterstützt werden können. 

Demgegenüber werden bei dem 64-bit- 

Betriebssystem durch steigenden Hauptspeicherausbau 

auch eine steigende Anzahl 

User erreicht, da keine Limitierungen durch 

Betriebssystemressourcen auftreten. 

Zusammenfassend kann man also feststellen, 

dass ein 32-bit-Betriebssystem bei Terminal 

Server limitierend wirkt, wenn entweder der für 

die gewünschte Anzahl Benutzer notwendige 

Arbeitsspeicher (> 64 GB) nicht unterstützt 

wird, oder es aufgrund der vielen Benutzer zu 

internen Kernel-Engpässen kommt. Dabei ist 

Zu wenig Speicher 

Engpass der 

Kernel-Ressourcen 

(Light Lastprofil, Microsoft Office 2003, 


der Speicherverbrauch eines einzelnen Benutzers natürlich anwendungsabhängig. Bestehen diese beiden 

Limitierungen nicht, so kann ein 32-bit-Betriebssystem durch geringeren Speicherverbrauch gegenüber dem 

64-bit-Betriebssystem punkten. 



Rechenleistung 

Die Rechenleistung eines Systems hängt von den Prozessoreigenschaften und der Anzahl Prozessoren ab. 

Unter Prozessoreigenschaften verstehen wir Kenngrößen wie z.B. Taktfrequenz, Cache, Hyper-Threading, 

Anbindung ans Memory oder Anzahl Kerne. Dabei sind Prozessoreigenschaften immer im Hinblick auf die 

jeweilige Prozessarchitektur zu sehen. 

Prozessortyp 

Folgende Übersicht zeigt Prozessoren verschiedener Generationen, die in älteren und aktuellen PRIMERGY 

Systemen für Terminal Server im Einsatz sind. Die Leistungsdaten gelten für jeweils eine CPU, wie sie mit 

dem Terminal Server Simulationswerkzeug »T4US« mit dem Lastprofil V1 bzw. V2 ermittelt wurden. Dabei 

sind alle Werte normiert zu den Ergebnissen der besten Xeon X5570 CPU aufgetragen. 

Bei der Betrachtung der Rechenleistung waren alle Systeme mit genügend Arbeitsspeicher ausgebaut. 

Hyper-Threading, sofern vorhanden, war eingeschaltet, da dieses Feature bei Terminal Server 

Anwendungen für eine Entlastung des Systems sorgt und dadurch eine höhere Anzahl von Benutzern mit 

dem Terminal Server arbeiten kann. Aus diesen Messergebnissen für eine CPU kann man die Leistung 

eines Systems mit einer höheren CPU-Anzahl nicht ablesen, da die Steigerung nicht linear ist (siehe Kapitel 

Anzahl Kerne). 



Taktfrequenz 

Prozessorlinien der PRIMERGY Server gibt es in verschiedenen Leistungsstufen, die sich unter anderem in 

der Taktfrequenz unterscheiden. Dabei sagt die Taktfrequenz für sich allein nichts über die 

Leistungsfähigkeit des Prozessors aus. Andere Faktoren wie Architektur, Befehlssatz, Caches, Anbindung 

ans Memory beeinflussen die Prozessoren in ihrer Leistungsfähigkeit ebenso. Man darf also nicht den Fehler 

machen, mit einer höheren Taktfrequenz immer eine höhere Performance zu verbinden. Deutlich wird das 

bei den Intel Xeon 55xx Prozessoren, die im Vergleich zu dem Vorgänger Xeon 54xx niedriger getaktet sind, 

sich dennoch als viel leistungsfähiger erweisen. Der Vorteil der niedrigen Taktfrequenz liegt in der 

niedrigeren elektrischen Leistungsaufnahme (Energieverbrauch). 

Durch die Einführung der Turbo Boost Technologie bei der Intel Xeon 55xx Serie ist die Kennzahl Frequenz 

auch nicht mehr so eindeutig. Bei dieser Technologie wird nämlich, abhängig von der Anwendung, der 

Prozessor automatisch beim Arbeiten unterhalb thermischer und elektrischer Schwellwerte übertaktet. 

Vereinfacht heißt das: Wenn der Prozessor nicht voll ausgelastet ist und die Thermal Design Power (TDP) 

nicht überschritten wird, wird der Prozessor höher getaktet. 

Vergleicht man Prozessoren einer Familie, die sich nur in der Taktfrequenz unterscheiden während die 

anderen Kenngrößen wie Architektur, Caches, Memory-Anbindung und Anzahl Kerne gleich sind, so lässt 

sich durchaus bei höherer Taktfrequenz auch eine höhere Performance nachweisen. Allerdings spiegelt sich 

die Frequenzsteigerung nicht 1:1 in der relativen Performance-Steigerung wider. Dies erklärt sich aus der 

gleich bleibenden Geschwindigkeit bei Speicher- und I/O-Zugriffen. 

Als Beispiel sind in nebenstehender Grafik die 

Ergebnisse der PRIMERGY RX300 S4 1-CPU- 

Messungen der Xeon 54xx Reihe aufgetragen. 

Die Resultate wurden mit dem Terminal Server 

Benchmark und dem Lastprofil V1 unter Microsoft 

Terminal Server erreicht und normiert auf den 

kleinsten Prozessor dargestellt. Alle Prozessoren 

haben einen Front-Side-Bus mit 1333 MHz und 

einen 2 × 6 MB L2-Cache. 

(Lastprofil V1, Microsoft Office 2003, 




Memory-Anbindung 

Die Memory-Anbindung ist bei den PRIMERGY Systemen je nach Prozessorarchitektur unterschiedlich. 

Bei PRIMERGY Systemen, die mit AMD Opteron Prozessoren bestückt sind, ist der Memory Controller in 

der CPU integriert und die Prozessoren untereinander sind durch einen HyperTransport-Link verbunden. 

Bei Intel Prozessoren bis zur Xeon 5400-Serie wird die Kommunikation über den Front-Side-Bus (FSB) 

zwischen dem Prozessor und der so genannten Northbridge abgewickelt. Die Northbridge ist ein Bestandteil 

des Chipsatzes, der wiederum mit anderen Komponenten wie zum Beispiel dem Arbeitsspeicher oder dem 

PCI-Bus verbunden ist. Der FSB wird mit einer bestimmten Taktrate betrieben, welche Einfluss auf die 

System-Performance hat. Da sich die Prozessoren im Allgemeinen aber nicht nur in der Taktfrequenz des 

FSBs unterscheiden, ist ein direkter Vergleich unterschiedlicher FSB schlecht möglich. 

Unter Laborbedingungen konnte der Einfluss des 

Front-Side-Bus-Taktes jedoch vermessen 

werden. Die Grafik zeigt die Performance- 

Verbesserung durch Steigerung der Front-Side- 

Bus-Taktfrequenz von 667 MHz auf 800 MHz, 

was einer Steigerung von ca. 20% entspricht. Die 

Anzahl der Terminal Server Benutzer steigt in 

allen drei vermessenen Konfigurationen. Ein 

schnellerer FSB entlastet den Prozessor, die »% 

Processor Time« ist bei 800 MHz FSB etwas 

niedriger und gleichermaßen auch die 

»Processor Queue Length«. Durch diese CPU- 

Reserve können mehr Benutzer mit dem 

Terminal Server arbeiten, bevor die Antwortzeiten 

sich verschlechtern und sich nicht mehr im 

zulässigen Rahmen befinden. Die Steigerung der 

Benutzeranzahl ist jedoch geringer als die 

Erhöhung der FSB-Taktfrequenz. Terminal 

Server als Anwendung beansprucht nicht nur 



Prozessorleistung, sondern zur Gesamtleistung trägt das Zusammenspiel aller Ressourcen wie Prozessor, 

Speicher, Netzwerk und Disk bei. 

Ab der PRIMERGY Generation mit Prozessoren der Serie Xeon 5500 (Nehalem EP) erfolgte ein Wechsel in 

der Systemarchitektur, weil die FSB Technologie hinsichtlich ihrer Komplexität, beispielsweise der Anzahl 

der im Chipset pro FSB benötigten Pins, zuletzt an Grenzen gestoßen ist: Intel Quick Path Interconnect 

(QPI) statt Front Side Bus (FSB). Der QPI verbindet Prozessoren untereinander, sowie Prozessoren und den 

für I/O zuständigen Chipsatz, mittels unidirektionaler, serieller Links. Für die Anbindung des Hauptspeichers 

sind die Prozessoren der Serie Xeon 5500 mit Speicher-Controllern ausgestattet, d.h. jeder Prozessor 

steuert unmittelbar eine Gruppe ihm zugeordneter Speichermodule. Die Leistungsfähigkeit des Quick-Path 

Interconnects wird in Gigatransfers pro Sekunde angegeben. Dabei erreichen die aktuellen Prozessoren der 

Xeon 5500 Serie mit einem QPI von bis zu 6.4 GT/s (entspricht bis zu 25.6 GByte/s) eine weit höhere 

Bandbreite als der stärkste Prozessor der Xeon 5400 Serie mit Hilfe der der Front-Side-Bus Architektur 

liefern konnte. 



Caches 

Ein Cache ist generell ein schneller Zwischenspeicher, der durch die Pufferung von Daten den Zugriff 

beschleunigt. Bei Intel-CPUs sind die Caches in mehreren Stufen kaskadiert. Man unterscheidet Level 1 

Cache, Level 2 Cache (auch Second Level Cache (SLC) genannt) und Level 3 Cache (Third Level Cache 

(TLC)). Meistens wird bei den Leistungsdaten der CPUs nur der jeweils letzte Cache genannt. Der Cache 

soll verhindern, dass der Prozessor auf Daten des langsameren Arbeitsspeichers warten muss. Je größer 

der Cache, umso weniger Speicherzugriffe sind nötig. Aus dieser Zeitersparnis resultiert wiederum eine 

höhere Rechenleistung. 

Vergleichende Messungen mit dem Terminal 

Server Benchmark zeigten, dass eine 

Verdoppelung des Caches zu einer Entlastung 

der CPU führte. Bei sonst gleichen Bedingungen 

wurden jeweils zwei Prozessoren 

einmal mit 1 MB Cache und einmal mit 2 MB 

Cache eingesetzt. Wie nebenstehende Grafik 

zeigt, wird der Prozessor des Terminal Server 

Systems bei dem größeren Cache weniger 

stark beansprucht. Daraus resultierte eine 

höhere Benutzeranzahl als Benchmark- 

Ergebnis. 

(Lastprofil V1, Microsoft Office XP, Citrix MetaFrame) 

Da beim 64-bit-Betriebssystem aufgrund der doppelt so großen Adressbreite mehr Daten verarbeitet werden 

müssen, hat die Größe des CPU-Caches hier einen größeren Einfluss. 

(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) 

Das gleiche PRIMERGY System 

wurde wahlweise mit Xeon 

Prozessoren mit 1 MB oder mit 

2 MB SLC ausgestattet. Wie 

nebenstehende Grafik zeigt, führt 

eine Verdoppelung des Caches 

auf beiden Plattformen zu einer 

höheren Performance. Das 64- 

bit-System profitiert am meisten 

von dem doppelt so großen 

Cache mit einem Performance- 

Gewinn von 25%. Das 32-bit- 

System gewinnt bis zu 15% mehr 

Leistung mit dem größeren 

Cache. Diese Messungen zeigen, 

dass ein 64-bit-System durch den 

Adress-Overhead einen größeren 

Cache benötigt. 

Eine generelle Empfehlung leitet sich aus diesen Ergebnissen ab: Für Systeme mit 64-bit-Betriebssystem 

sollten in jedem Fall Prozessorvarianten mit einem großen Cache eingesetzt werden. Dies ist wichtiger als 

eine geringfügig höhere Taktfrequenz. 

Allerdings sollte nicht der Fehler begangen werden, Cache-Größen von Prozessoren mit unterschiedlicher 

Architektur zu vergleichen. Die Caches der Prozessoren sind auf die Prozessorarchitektur abgestimmt. So 

haben z.B. aktuell Prozessoren der Serie Xeon 5500 (Nehalem) mit 256 kB per Core SLC und maximal 

8 MB TLC für alle vier Kerne nominell weniger Cache als Prozessoren der Serie Xeon 5400 (Harpertown) mit 

2 × 6 MB SLC. Trotzdem ist die Gesamtleistung der Prozessoren weit höher. 



Hyper-Threading 

Bei Hyper-Threading-Prozessoren sind einige Ressourcen auf dem Chip verdoppelt, so dass diese CPUs 

nun die Fähigkeit besitzen, zwei Threads parallel ausführen zu können. So werden zwei virtuelle bzw. 

logische CPUs simuliert. Dem Betriebssystem gegenüber stellt sich eine CPU mit Hyper-Threading als zwei 

CPUs dar und wird auch so angesteuert. Dies bringt einen Geschwindigkeitsvorteil, wenn Betriebssystem 

und Anwendungen dafür geeignet sind. Windows als Betriebssystem ist vom Design her Hyper-Threadingfähig 

und gerade in Terminal Server Umgebungen arbeiten viele einzelne Benutzer mit insgesamt vielen, 

meist kleineren Anwendungen parallel, so dass von Hyper-Threading eine Performance-Steigerung zu 

erwarten ist. 

Die meisten Intel Prozessoren der aktuellen Xeon 5500 Serie (Nehalem) unterstützen Hyper-Threading. 

AMD Prozessoren besitzen grundsätzlich kein Hyper-Threading. 

Messungen haben gezeigt, dass der Performance-Gewinn durch Hyper-Threading bei gering bis mittel 

belasteten Systemen am größten ist. Bei Systemen, die an ihrer Lastgrenze arbeiten, ist der Performance- 

Gewinn geringer. Auch ist die Leistungssteigerung auf einem Monoprozessorsystem höher als auf 

Multiprozessorsystemen. 

Eine Messreihe wurde auf einer PRIMERGY RX200 S1 

mit zwei Prozessoren durchgeführt, einmal mit 

eingeschaltetem Hyper-Threading und einmal mit 

abgeschaltetem Hyper-Threading. In beiden Fällen 

wurde die gleiche Anzahl von 101 Benutzern simuliert. 

Bei Terminal Server Anwendungen sorgt das Hyper- 

Threading für eine Entlastung des Systems, die CPU- 

Last konnte um 31% reduziert werden, wie die 

nebenstehende Grafik veranschaulicht. Bei der 

verwendeten PRIMERGY RX200 S1 und 101 Benutzern 

konnte man ohne Hyper-Threading schon einen CPU 

Engpass feststellen, die Antwortzeiten des Terminal 

Servers waren nicht mehr im vorgegebenen Rahmen. 

Durch die CPU Entlastung durch Hyper-Threading 

erfüllte das System wieder die vorgegebene 

Reaktionszeit. 

(Lastprofil V1, Microsoft Office XP, 

Citrix MetaFrame) 

In einer weiteren Messreihe 

wurden die absoluten Benutzeranzahlen 

für Systeme mit und 

ohne Hyper-Threading ermittelt. 

Die nebenstehende Grafik zeigt 

die Messergebnisse. Das 

vermessene PRIMERGY System 

war eine PRIMERGY RX300 S2 

mit einem oder zwei Prozessoren 

mit verschiedenen Taktfrequenzen. 

Für diesen Vergleich 

wurden Prozessoren mit 1 MB 

SLC verwendet. Hyper-Threading 

war alternativ ein- (»HT on«) oder 

ausgeschaltet (»HT off«). Man 

erkennt deutlich, dass mit eingeschaltetem 

Hyper-Threading 


eine höhere Anzahl Benutzer mit 

dem Terminal Server arbeiten können. Bei einem langsameren Monoprozessorsystem ist der Performance- 

Gewinn durch Hyper-Threading höher als bei einem schnellen Dualprozessorsystem. 



Anzahl Kerne 

Eine gängige Variante um die Leistungsfähigkeit eines Prozessors zu steigern, ist die Erhöhung durch die 

Taktfrequenz. Doch dies geht bei Frequenzen um 4 GHz mit einer nicht mehr sinnvoll handhabbaren 

Abwärme einher. Eine Möglichkeit der Fortentwicklung ist die Verwendung von Mehrkernprozessoren. Im 

Gegensatz zum »Hyper-Threading«, wo nur Teile eines Prozessors mehrfach auf dem Chip vorhanden sind 

um Threads parallel ausführen zu können, sind bei einem Mehrkernprozessor sämtliche Ressourcen des 

Prozessors repliziert. Mehrkernprozessoren haben zudem den Vorteil, dass die Kosten für den Einsatz eines 

einzelnen Chips mit mehreren Ressourcen häufig geringer sind als bei mehreren einzelnen Chips. Während 

bis zum Jahr 2005 die Einzelkernprozessoren dominierten, sind die aktuellen Prozessoren der Intel Xeon 

Reihe als 4-fach oder auch 6-fach Kerne ausgelegt. Zukünftige Prozessorgenerationen werden die Anzahl 

Kerne pro Chip noch vervielfachen. 

Die rein theoretische Leistungssteigerung beträgt maximal 100% (gegenüber einem einzelnen Kern) pro 

zusätzlichem Kern. In der Praxis hängt die Leistungssteigerung aber stark von dem Parallelisierungsgrad 

des ausgeführten Programms und des verwendeten Betriebssystems ab. 

Darüber hinaus lässt sich die Rechenleistung eines 

Systems durch den Einsatz mehrerer Prozessoren 

erhöhen. Man bezeichnet den Einsatz mehrerer 

gleicher physikalischer Prozessoren auch als 

»symmetric multiprocessing« (SMP). Die 

Skalierung mit wachsender Anzahl Prozessoren ist 

nur im Idealfall einer optimal parallelisierbaren 

Anwendung linear. Je mehr Zugriffe jedoch auf 

gemeinsame Ressourcen wie Arbeitsspeicher, 

Festplatten oder Netzwerk erfolgen, und somit eine 

Koordination zwischen den Prozessoren bedingen, 

umso mehr flacht die Skalierungskurve ab. Im 

Extremfall kann es bei einer sehr großen Anzahl 

Prozessoren und sehr hohem Koordinationsanteil 

der Prozessoren untereinander sogar zu einem 

»Umkippen« der Skalierung kommen. Schon 1967 

betrachtete Gene Amdahl die Beschleunigung von Programmen durch parallele Ausführung in einem 

mathematischen Modell und stellte fest, dass der Geschwindigkeitszuwachs vor allem durch den 

sequentiellen Anteil des Programms beschränkt ist (»Amdahls Gesetz«). 

Aktuelle Multiprozessorsysteme wirken dem entgegen, indem sie den Prozessoren große Caches beiseite 

stellen oder Gruppen von Prozessoren bilden und diesen eigenen Arbeitsspeicher und I/O-Komponenten 

zuordnen. Letzteres bedingt für optimale Performance darauf angepasste Betriebssysteme wie z.B. 

Windows Server 2003 Enterprise und Datacenter Edition mit »nonuniform memory access« (NUMA) 

Support. 

Wie schon im Kapitel Hyper-Threading ausgeführt, 

arbeiten in Terminal Server Umgebungen viele 

einzelne Benutzer mit insgesamt vielen, meist 

kleineren Anwendungen parallel – eine gute 

Voraussetzung, um viele Rechenkerne zu nutzen. Bis 

zu welcher Anzahl Kerne eine Terminal Server 

Anwendung gut skaliert ist aber auch wieder 

anwendungsspezifisch und kann nicht verallgemeinert 

werden. 

Wie in der nebenstehende Grafik dargestellt, zeigten 

Terminal Server Messungen mit dem T4US Lastprofil 

V2 auf einer PRIMERGY RX300 S5 mit einem und 

zwei Xeon Quad-Core Prozessoren bei eingeschaltetem 

Hyper-Threading eine sehr gute 

Skalierung vom Faktor 1.7. 





Arbeitsspeicher 

Den stärksten Einfluss auf die Leistungsfähigkeit des Terminal Servers übt der Arbeitsspeicher aus. Dabei 

spiegelt sich dies insbesondere in der Antwortzeit wider. Denn Windows verschafft sich bei Bedarf weiteren 

virtuellen Speicher durch Auslagern (Pagen) von momentan nicht benötigten Daten aus dem Arbeitsspeicher 

(RAM) in die Auslagerungsdatei (Pagefile) auf Festplatte. Da Plattenzugriffe aber mindestens um die 

Größenordnung 1000 langsamer sind als Speicherzugriffe, führt dies unmittelbar zum Zusammenbruch der 

Leistung und zu einem rapiden Anstieg der Antwortzeiten. 

Bei Terminal Server wächst der Speicherbedarf linear mit der Anzahl der Benutzer, unabhängig vom 

PRIMERGY Modell und gleichermaßen bei 32-bit- und 64-bit-Betriebssystemen, wie die beiden Grafiken 

veranschaulichen. 

Trägt man den belegten Speicher, den »Committed« Speicher und den »Working Set« grafisch auf, so 

erkennt man einen linearen Verlauf, der mit steigender Benutzeranzahl wächst. Während »Available 

MBytes« den aktuell freien physikalischen Hauptspeicher angibt, wird in »Committed Bytes« angegeben, wie 

viel virtueller Hauptspeicher den laufenden Anwendungen zugesagt wurde. Der »Working Set« einer 

Anwendung ist der Speicher, den sie bereits verwendet hat. 

Es soll auch nicht verschwiegen werden, dass 64-bit-Betriebssysteme und 64-bit-Anwendungen in der Regel 

mehr Arbeitsspeicher benötigen als die 32-bit-Versionen, denn alle Adresszeiger sind bei 64-bit doppelt so 

breit. Im Extremfall führt das bei 64-bit zu einem doppelten Speicherbedarf im Vergleich zu 32-bit. 

Wie die nebenstehende Grafik zeigt, 

belegt der gleiche Benutzer, der den 

Desktop gestartet hat und mit Microsoft 

Word 2003 arbeitet, auf dem 64-bit- 

System im Vergleich zum 32-bit-System 

ca. 60% mehr Arbeitsspeicher. Die 

Anwendung, mit der der Terminal Server 

Benutzer arbeitet, ist in beiden Fällen 

Microsoft Word, welches heute nur als 32- 

bit-Version existiert. 


Allgemeingültig ist jedoch die Tatsache, dass der Speicherbedarf linear nach der Formel 

anwächst. 

Man beachte dabei nur, dass der Speicherbedarf pro Benutzer stark von der verwendeten Anwendung 

abhängt und jeweils kundenspezifisch ermittelt werden muss. Kennt man jedoch den Speicherbedarf der 

Anwendung bei einem Benutzer, so lässt sich leicht der Gesamt-Speicherbedarf berechnen. 



Nach oben begrenzend wirken nur der maximal mögliche Speicherausbau des Systems sowie die 

Unterstützung des Betriebssystems (siehe Kapitel Limitierungen). 

Der maximale Speicherausbau eines Systems ist abhängig vom Modell. 

Die x86-basierten PRIMERGY Server haben unterschiedliche Architekturen. Die älteren Modelle (von Intel 

Pentium Pro Prozessor (1995) bis Intel Xeon 5400 (Harpertown)) entsprechen dem Prinzip des Symmetric 

Multiprocessing (SMP). Die Anbindung der Prozessoren an den Hauptspeicher ist durch einen Front-Side 

Bus realisiert ist. Auch bei der Bestückung mit nur einem Prozessor ist der gesamte Speicher nutzbar. 

Intel Xeon Prozessoren ab der Xeon 5500 Serie unterliegen einer anderen Architektur. Für die Anbindung 

des Hauptspeichers sind diese Prozessoren mit Speicher-Controllern ausgestattet, d.h. jeder Prozessor 

steuert unmittelbar eine Gruppe ihm zugeordneter Speichermodule. Gleichzeitig ist der Prozessor in der 

Lage, über den Quick Path Interconnect Speicherinhalte dem benachbarten Prozessor zur Verfügung zu 

stellen und solche selbst anzufordern (siehe Kapitel Memory-Anbindung). Durch die direkte Kopplung 

zwischen Prozessor und Speicher ist eine Steigerung der Speicher-Performance plausibel, jedoch mit dem 

Performance-Unterschied zwischen lokaler und ferner Anforderung, der die Klassifizierung dieser Architektur 

als NUMA rechtfertigt. Die Berücksichtigung von NUMA bei der Vergabe von physikalischem Speicher und 

beim Scheduling von Prozessen erfolgt durch das Betriebssystem. Soweit möglich, sollte die Gesamtmenge 

an Arbeitsspeicher symmetrisch über beide Prozessoren verteilt werden. Ist das System nur mit einem 

Prozessor bestückt, können auch nur die diesem Prozessor zugeordneten Speicherbänke genutzt werden. 

Weitere Performance-relevante Hinweise zu leistungsfähigen Speicherkonfigurationen der Xeon 5500 

basierten PRIMERGY Systeme finden sich im Dokument »Speicher-Performance Xeon 5500 (Nehalem EP) 

basierter PRIMERGY Server« [L4]. 

Auch PRIMERGY Modelle mit AMD Opteron Prozessoren besitzen eine direkte Zuordnung des Speichers zu 

den Prozessoren. Jeder Prozessor hat »seinen« Speicher direkt angebunden, was in einem schnellen 

Zugriff resultiert. Aus dieser Systemarchitektur folgt umgekehrt, dass eine PRIMERGY, die lediglich mit 

einem AMD Opteron Prozessor bestückt ist, auch nur die Hälfte der Speicherbänke nutzen kann, da der 

zweite CPU-interne Memory Controller zur Ansteuerung fehlt. 

Bei der Kalkulation des Arbeitsspeichers für Terminal Server sollte man zwei Besonderheiten nicht außer 

Acht lassen: 

»Desktop« oder »Published Application«? 

Bei Terminal Server Umgebungen muss man dem Benutzer nicht den gesamten Desktop mit allen 

Anwendungen zur Verfügung stellen, man kann den Zugriff auch beschränken. Microsoft Terminal 

Server kann man so konfigurieren, dass eine bestimmte Anwendung statt des Desktop gestartet wird. 

Bei Citrix Presentation Server kann man den Benutzern auch mehrere einzelne Anwendungen 

(»Published Application«) direkt zur Verfügung stellen, der Start der Applikation innerhalb des Desktop 

entfällt. Dabei werden pro Benutzer ungefähr 5 bis 10 MB an Hauptspeicher gespart, da der Explorer- 

Prozess nicht mit gestartet werden muss. Auch wenn es in einer bestimmten Umgebung vielleicht nicht 

um diesen kleinen Gewinn von Hauptspeicher geht; ein nicht zu vernachlässigender Vorteil dieser 

Konfiguration ist, dass der Benutzer nur die für ihn vorgesehenen Anwendungen auf dem Server laufen 

lassen kann. Man kann also die Aktionen der Benutzer besser vorhersagen und auch einschränken. 

Der Speicherbedarf eines Benutzers, der 

eine Anwendung über den Desktop startet, 

wurde mit dem Speicherbedarf eines 

Anwenders verglichen, der die gleiche 

Applikation direkt ohne Desktop startet. Die 

Anwendung Microsoft Word aus Microsoft 

Office 2003 wurde einmal über den Desktop 

und einmal über den RDP Client direkt 

gestartet. Wie nebenstehe Graphik deutlich 

zeigt, ist der Speichermehrverbrauch ohne 

Starten des Desktops geringer. 





»Logoff« oder »Disconnect«? 

Es ist ein Unterschied, ob der Benutzer die Verbindung zum Terminal Server beendet, indem er sich 

abmeldet (»Logoff«) oder ob er mit einem »Disconnect« die Verbindung nur unterbricht. Im letzteren 

Fall läuft die Anwendung auf dem Terminal Server weiter und gibt ihre Ressourcen nicht frei. Der 

Benutzer kann seine Arbeit dann an dieser Stelle fortsetzen. Wenn der belegte Arbeitsspeicher des 

Servers analysiert wird, zählen die Verbindungen im Status »Disconnect« natürlich mit. Manche 

Anwendungen brauchen auch CPU-Ressourcen, während die Verbindung getrennt ist. Sowohl 

Microsoft als auch Citrix unterstützen »disconnected« Sessions. 



Disk-Subsystem 

Geht man davon aus, dass ein Server dediziert als Terminal Server eingesetzt wird, und nicht gleichzeitig 

noch als File Server oder Datenbank-Server, so werden an das Disk-Subsystem keine großen 

Anforderungen gestellt. Es muss im Wesentlichen nur das Betriebssystem, den Paging-Bereich und die den 

Terminal Server Clients zur Verfügung stehenden Applikationen beherbergen. Die Plattenzugriffe sind dabei 

gering. Auf das Betriebssystem und die Applikationen wird nur zugegriffen, wenn sie das erste Mal in den 

Speicher geladen werden. Der Paging-Bereich spielt prinzipiell auch keine Rolle, denn das System muss so 

konfiguriert sein, dass es nicht in starkes Pagen gerät, anderenfalls ist die Leistungsfähigkeit des Systems in 

jedem Fall erheblich beeinträchtigt. 

Die Benutzerdaten und Benutzerprofile werden typischerweise auf entsprechende Disk-Subsysteme oder 

externe File Server gelegt und nicht auf die lokalen Festplatten eines Terminal Servers. 

Wird ein Terminal Server auf moderner Server-Hardware mit Multi-Core-Architektur und ggf. einem 64-bit- 

Betriebssystem aufgebaut, so können damit mehr Benutzer arbeiten und somit muss auch das Disk- 

Subsystem wachsen, um diesen Anforderungen gerecht werden zu können. Durch mehr Benutzersitzungen 

finden mehr Zugriffe auf das lokale Pagefile und auf das Disk-Subsystem statt und beim 64-bit- 

Betriebssystem werden auch größere Datenmengen Richtung Pagefile geschrieben. Aus diesen Gründen 

muss das Disk-Subsystem entsprechend dimensioniert werden. Hinweise zum Monitoren des Disk- 

Subsystems finden sich im Kapitel Engpassanalyse. 

Um einen maximalen Durchsatz zu erreichen, sollten alle vorhandenen Controller- und Festplatten Caches 

(auch die Write-Caches) eingeschaltet werden. Write-Caches der Festplatten tragen erheblich zur 

Performance-Steigerung bei, und es empfiehlt sich, diese bei allen Festplatten vorhandene Funktionalität 

auch im produktiven Einsatz zu nutzen. Dabei ist die Verwendung einer USV zum Schutz gegen 

Stromausfälle und damit verbundenem Datenverlust empfehlenswert. 

Zum Sizing von Disk-Subsystemen wurde ein eigenes White Paper »Performance Report - Modular RAID für 

PRIMERGY« [L5] erstellt. 

Wird das Terminal Server System hingegen gleichzeitig noch als Datei- oder Datenbank-Server eingesetzt, 

so gelten für das Disk-Subsystem natürlich zusätzliche Kriterien, wie sie für Datei- oder Datenbank-Server 

typisch sind. Von einer solchen Konstellation ist jedoch abzuraten, es sei denn, das System wird nur in 

einem sehr begrenzten Workgroup-Umfeld eingesetzt. Ansonsten sollten dedizierte Systeme für die 

einzelnen Aufgaben, wie Terminal Server, Datei-Server, Datenbank- oder Applikations-Server, aufgebaut 

werden. Nur so kann ein Server-System optimal für seinen Aufgabenbereich zugeschnitten werden. 

Je nach Anzahl Festplatten im Server-System gelten folgende Empfehlungen: 

Zwei Festplatten, Konfiguration für Sicherheit: Wenn nur zwei Festplatten zur Verfügung stehen und auf 

Sicherheit Wert gelegt wird, so sollte aus Sicherheitsgründen eine Spiegelung über RAID 1 eingerichtet 

werden. Dort befinden sich dann Betriebssystem, Paging-Bereich und Applikationen. Eine Spiegelung kann 

entweder mit den onboard RAID 1-Funktionalitäten, die fast alle PRIMERGY Server standardmäßig bieten, 

oder softwaremäßig mit Windows Mitteln realisiert werden. Alternativ kann auch ein RAID-Controller 

eingesetzt werden. 

Zwei Festplatten, Konfiguration für Performance: Um eine bessere Performance zu erreichen, sollte das 

Pagefile nicht auf einer gespiegelten Festplatte konfiguriert werden. Wenn nur zwei Festplatten zur 

Verfügung stehen, sollten das Betriebssystem und die Applikationen auf der ersten Festplatte gespeichert 

werden, während das Pagefile auf die zweite Festplatte gelegt werden sollte. Da die Festplatte des 

Betriebssystems nicht gespiegelt ist, sollte sichergestellt werden, dass dort keine Benutzerdaten abgelegt 

und dass regelmäßige Backups durchgeführt werden. 

Drei oder mehr Festplatten: Stehen insgesamt mindestens drei Festplatten zur Verfügung, sollte man zwei 

Festplatten mit Hilfe von RAID 1 spiegeln und dort das Betriebssystem und die Applikationen unterbringen. 

Der Paging-Bereich wird auf die dritte dedizierte Festplatte gelegt, da die Nutzung einer gespiegelten 

Festplatte durch das Pagefile beträchtliche Auswirkungen auf die Performance haben kann. Da diese Daten 

alle temporärer Natur sind, ist hier natürlich keine Absicherung durch RAID notwendig. 



Netzwerk 

Obwohl dem Thema Netzwerk im Terminal Server Umfeld eine wichtige Rolle zukommt, wird es im Rahmen 

dieses Papieres nicht ausführlich behandelt, da es ein eigenständiges Thema darstellt. Auch soll hier ein 

einzelner Terminal Server und nicht eine Terminal Server Farm im Focus stehen. In der Praxis sind zudem 

häufig schon Netzwerk-Topologien vorhanden, in die der Terminal Server zu integrieren ist. 

Bei der Betrachtung eines einzelnen Terminal Servers ist zu berücksichtigen, dass er bezüglich 

Netzwerkanbindung die benötigten Bandbreiten für alle Benutzer zur Verfügung stellt. Welche Bandbreiten 

für den Terminal Server benötigt werden, ist dabei stark vom Benutzer abhängig. Benutzer, die z.B. mehr im 

Office-Umfeld mit Textverarbeitung zu tun haben, benötigen weniger Bandbreite als Nutzer von 2D- oder 3D- 

Anwendungen. Ebenso spielt das verwendete Übertragungsprotokoll eine Rolle. Dabei hat sich das von 

Citrix entwickelte ICA-Protokoll als effizienter erwiesen als RDP von Microsoft. 

Aktuelle PRIMERGY Server bieten mit ihren Gigabit Ethernet Anschlüssen eine gute Voraussetzung, um 

einen Terminal Server performant zu betreiben. 

Bedingt es das Aufgabenszenario, dass die auf dem Terminal Server ablaufenden Anwendungen auf große 

Datenmengen, Datenbanken oder gar Host-Anwendungen zugreifen, so empfiehlt es sich, den Terminal 

Server mit einer weiteren Netzwerkkarte für den dedizierten Zugriff auf diese Server-Dienste auszustatten, 

um so den Datenverkehr in dieser Three-Tier-Umgebung zwischen Server-Server- und Client-Server- 

Kommunikation zu trennen. 

Application Server 


Database Server 

File Server 

Network 

Network 

In einer Terminal Server Umgebung muss folgender Netzwerkverkehr berücksichtigt werden: 

Terminal Server und Active Directory 

Hauptsächlich während des Anmeldevorgangs der einzelnen Benutzer in die Domäne werden 

Informationen aus dem Active Directory benötigt. Dies wird in realen Konfigurationen oft auch über ein 

Netzwerksegment abgewickelt, das von den Client-Netzwerken getrennt ist. 

Clients und Terminal Server 

Tastatur- und Mauseingaben werden zum Terminal Server gesendet, und die Änderungen der Bildschirmdarstellung 

werden zum Client übertragen. 



Infrastruktur 

In unseren Untersuchungen haben wir den Terminal Server immer isoliert betrachtet. In der Messumgebung 

gab es weitere Komponenten, mit denen der Terminal Server zusammen arbeitet, jedoch waren diese immer 

konstant und so ausgelegt, dass diese nicht der Engpass waren. In der Realität ist dies jedoch nicht immer 

der Fall. In diesem Abschnitt soll diskutiert werden, welche weiteren Komponenten der Infrastruktur einen 

Einfluss auf das Benutzerempfinden in einer Terminal Server Umgebung haben, was sich in einem 

negativen Gesamteindruck widerspiegeln könnte. 

Clients 

Neben den Server-Ressourcen und dem Netzwerk gehört natürlich auch der Client zur Gesamtumgebung 

des Server-based Computing. Also ist auch bzgl. des Clients die Frage berechtigt, welchen Einfluss dessen 

Leistungsfähigkeit auf die Gesamtkonfiguration hat. Da beim klassischen Server-based Computing die 

eigentliche Applikation auf dem Server abläuft, wird die CPU-Leistung des Clients nur für die Bedienung des 

Netzwerks und die vom Aufwand her nicht zu vernachlässigende Bildaufbereitung benötigt. Es wurde 

festgestellt, dass je nach verwendetem Client-System die Gesamt-Ausführungszeit einer Applikation 

durchaus variiert. Diese Unterschiede dürften sich im realen Betrieb aber allenfalls in einem subjektiven 

Performance-Eindruck des Benutzers widerspiegeln und haben keinen unmittelbaren Einfluss auf die 

Leistungsfähigkeit des Terminal Server Systems. 

Wie »thin« der Thin-Client sein darf, hängt in erster Linie von den Ansprüchen seitens der eingesetzten 

Applikationen an die Grafik ab, wie Auflösung, Farbtiefe und Komplexität (Text, Grafik) sowie von ggf. 

zusätzlichen Anforderungen an lokal auf dem Client ablaufende Anwendungen, die über das reine Serverbased 

Computing hinausgehen. 

Neben den ortsgebundenen (Thin-)Clients gibt es die Anforderungen auch mobile Geräte wie Notebooks 

oder PDAs an Terminal Server anzuschließen. Üblicherweise werden diese Geräte dann nicht mehr über 

kabelgebundene Netzwerke angeschlossen, sondern über Funk-LANs (W-LAN) oder mobile Funknetze (z.B. 

»General Packet Radio Services« (GPRS) oder »Universal Mobile Telecommunication System« (UMTS)). 

Dies stellt insbesondere beim Ressourcen sparenden ICA-Protokoll kein Problem dar. Den ICA-Client gibt es 

auch für viele gängige PDAs und das ICA-Protokoll ist durch sein Design besonders auch für langsame 

Verbindungen geeignet. Für Benutzer, die ständig und ausschließlich mit Terminal Server Anwendungen 

arbeiten, stellt solch ein Endgerät sicher nicht den idealen Client dar, aber jemand, der mobil arbeiten muss 

und nur gelegentlich Zugriff auf einen Terminal Server braucht, profitiert von der Flexibilität und 

Funktionalität dieser Lösung. 

Active Directory 

Terminal Server Benutzer authentifizieren sich im Normalfall in einer Domäne, d.h. der Terminal Server 

überprüft die eingegebenen Benutzercredentials gegen das Active Directory. Außer in sehr kleinen 

Workgroup-Umgebungen sollten Active Directory und Terminal Server immer auf verschiedenen Systemen 

laufen und auf dem Terminal Server selbst sollten keine Benutzer verwaltet werden. An das Active Directory 

werden die gleichen Anforderungen gestellt wie in einer Umgebung ohne Terminal Server, es sollte aber 

weder das Active Directory noch das Netzwerk zwischen Active Directory und Terminal Server der Engpass 

sein. 

Benutzerprofile (User Profiles) 

In einem Benutzerprofil werden die individuellen Benutzereinstellungen gespeichert. Auch bei einem Login 

von Terminal Server Benutzern in einer Domäne in einem Active Directory Umfeld würden deren 

Benutzerprofile standardmäßig auf dem Terminal Server gespeichert. Insbesondere bei einer load-balanced 

Terminal Server Farm wird man die Benutzerprofile allerdings zentral auf einem Server im Netzwerk ablegen 

wollen, damit der Benutzer immer die gleichen Einstellungen vorfindet, unabhängig davon, auf welchem 

Terminal Server seine Sitzung ausgeführt wird. Diese Funktionalität ist bereits für so genannte »Wandernde 

Benutzer« (Roaming User) vorhanden, die sich an verschiedenen Arbeitsplätzen anmelden. Beim Einsatz 

von Terminal Servern ist zu beachten, dass ggf. verschiedene Benutzerprofile verwaltet werden müssen, 

wenn sich nämlich das lokale Betriebssystem des Arbeitsplatzes von dem des Terminal Servers 

unterscheidet bzw. wenn verschiedene Anwendungen vorhanden sind. Aus diesem Grunde kann man ein 

Terminal Server Benutzerprofil zusätzlich zu einem lokal zu ladenden Benutzerprofil konfigurieren. Eine 

besondere Variante des Server-basierten Benutzerprofils ist das Mandatory User Profile, ein Benutzerprofil, 

das der Benutzer nicht ändern kann. Server-basierte Benutzerprofile sollten generell möglichst klein sein. 



DNS 

Auch im Terminal Server Umfeld wird DNS verwendet, um die Namensauflösung von Verbindungen zu 

realisieren. Besonders im Load Balancing Umfeld wird auf diese Weise ein virtueller Name mit einer 

virtuellen oder realen IP-Adresse verknüpft, so dass sich eine Terminal Server Farm zum Benutzer hin wie 

ein Server darstellt. Daraus ergibt sich umgekehrt die Forderung, dass DNS immer erreichbar sein muss, 

damit ein Benutzer eine Verbindung zum Terminal Server aufbauen kann. DNS stellt im Allgemeinen keinen 

Engpass dar, dieser Dienst sollte nur ausfallsicher und redundant konzipiert sein. 

Terminal Services Licensing Server 

Bei der Anmeldung eines Benutzers an einen Terminal Server wird dieser einen Lizenz-Server suchen und 

von ihm eine gültige Lizenz für den Zugriff über Terminal Server anfordern. In größeren Konfigurationen wird 

dieser Lizenz-Server ein eigenes System sein. 

Backend Server 

Gerade in »load-balanced Terminal Server Farmen« werden die Dateien der Benutzer nicht auf den lokalen 

Festplatten der Terminal Server Systeme liegen, sondern auf File Servern oder NAS Systemen. Vermutlich 

werden in größeren Umgebungen auch weitere Dienste wie E-Mail, Datenbanken usw. benötigt, so dass 

man Server für Anwendungen wie zum Beispiel Exchange, SQL oder SAP R/3 zusammen mit dem Terminal 

Server vorfinden wird. Wird für die Anbindung der Clients zum Terminal Server nur wenig 

Netzwerkbandbreite benötigt, so gilt dies nicht für die Anbindung der Terminal Server an die Backend 

Server. Hier sollte genügend Netzwerk- und Rechenkapazität zur Verfügung stehen. Für die einzelnen 

Server verweisen wir auf eigene Performance-Untersuchungen und Sizing Guides, da dies den Rahmen 

dieses Papiers sprengen würde. Es wird nicht empfohlen, Backend-Dienste auf einem Terminal Server zu 

betreiben. 



Überlastverhalten 

Bei allen PRIMERGY Servern, insbesondere aber bei den leistungsfähigeren, kann man ein Verhalten 

beobachten, bei dem ein scheinbar normal ausgelastetes System durch das Hinzufügen einiger weniger 

Benutzer überlastet wird. Setzt man die Anzahl Benutzer, die CPU-Auslastung des Systems und die 

Antwortzeiten miteinander in Beziehung, so erkennt man, wie sich die Antwortzeiten des Terminal Servers 

bei steigender Auslastung verhalten. Während einer Messung über 25 Minuten wurde in den ersten 15 

Minuten die Benutzeranzahl kontinuierlich erhöht. Jeder Benutzer meldet sich erst an, danach arbeitet er mit 

Microsoft Word, um sich nach ca. 16 Minuten wieder abzumelden und wieder von vorn zu beginnen. 

Dadurch verteilen sich die 

Benutzeranmeldungen (blaue Kurve 

) auf einen relativ kurzen Zeitraum, 

was aber der Realität nahe kommt, 

wenn die Benutzer etwa zur gleichen 

Zeit ihre Arbeit aufnehmen. Die CPU 

 

Auslastung des Terminal Servers 

stieg ständig an (rote Kurve ) bis 

nah an 100%. Zwei signifikante 

Messergebnisse wurden beobachtet: 

 

Die Zeit, die der Benutzer brauchte, 

 

um sich am Terminal Server 

 

anzumelden (violette Kurve ) und 

die Zeit, um in Microsoft Word ein 

Bild einzufügen (grüne Kurve ). 

Eine Anmeldung an den Terminal 

Server beinhaltet nicht nur das Login 

selbst, sondern auch der Desktop 

des Benutzers wird gestartet. Dies 

belastet den Terminal Server mehr als das Einfügen des Bildes in Microsoft Word. Aktionen, die von sich aus 

den Terminal Server stark belasten, werden unter Hochlast stärker verlangsamt als weniger belastende 

Aktionen. Man erkennt drei Phasen der Terminal Server Auslastung: 

Die CPU-Belastung des Terminal Servers ist unter 70%. Die Antwortzeiten des Servers verlängern 

sich geringfügig, dies wird der Benutzer aber nicht realisieren. 

Die CPU-Belastung des Terminal Servers ist zwischen 70% und 90%. Aktionen, die den Server 

stärker belasten, sind verlangsamt, aber die Antwortzeit ist für den Benutzer noch tolerierbar. 

Aktionen, die den Server nicht so stark belasten, haben im Durchschnitt die gleichen 

Reaktionszeiten, jedoch können Schwankungen auftreten. 

Wenn die CPU-Belastung des Terminal Servers über 90% ist, ist der Server deutlich überlastet. Je 

nach Benutzeraktion antwortet der Server wesentlich später, speziell Aktionen wie ein Login 

brauchen deutlich mehr Zeit. Aber auch einfachere Aktionen sind deutlich verlangsamt. Der 

Benutzer wird das Antwortzeitverhalten des Servers nicht mehr tolerieren. 

Anzahl Prozesse 

Auch wenn es paradox klingt: es kann Konstellationen geben, in denen, obgleich ausreichend CPU- und 

Speicher-Ressourcen zur Verfügung stehen, es zu Leistungsengpässen kommen kann. Auch Disk-I/O oder 

Netzwerke stellen in dieser Situation keinen Engpass dar, sondern quasi die Systemarchitektur. Diese 

Situation wird insbesondere von einer großen Anzahl an Benutzern, die viele Prozesse mit einer geringen 

gleichmäßigen Last induzieren, provoziert. Dabei spielt die Prozessor-Warteschlange eine nicht zu 

vernachlässigende Rolle. So gibt es in Abhängigkeit der Prozessor-Leistung und Prozessor-Anzahl einen 

Punkt, an dem das System keine weiteren Prozesse und somit Clients mehr bedienen kann. Im Prinzip ist 

hierbei das System nur noch damit beschäftigt, die Prozesse zu verwalten. Oder in »Fachchinesisch« 

ausgedrückt: In einem Multitasking-Betriebssystem erhält jeder Prozess eine Zeitscheibe, die er nicht schnell 

genug wieder frei gibt. Diese Situation könnte nur durch kleinere Zeitscheiben und somit größeren Turn- 

Around-Zeiten behoben werden. Dies hätte jedoch in anderen Lastsituationen negative Auswirkungen auf 

die Grundlast, die das Betriebssystem erzeugt. Die Anzahl Prozesse, ab der diese Situation eintritt, hängt 

neben der zur Verfügung stehenden CPU-Leistung und -Anzahl leider aber auch von der verwendeten 

Applikation ab, sodass keine generelle Formel hierfür angegeben werden kann. Bei Heavy Usern tritt dieser 

Effekt meist nicht zu Tage, da hier andere Ressourcen, wie Speicher und Rechenleistung die dominierenden 

Begrenzungsfaktoren sind. 



PRIMERGY Skalierung 

Die Leistungsfähigkeit des Terminal Servers ist durch CPU-Leistung und Hauptspeicher bestimmt. 

Den Speicherausbau kann man recht einfach anhand der Formel 

abschätzen. Werden verschiedene Applikationen gleichzeitig verwendet, so ist die Summe des Speicherbedarfs 

aller gleichzeitig verwendeter Applikationen zu bilden. 

Die Anzahl Benutzer bei einer vorgegebenen Speichermenge kann mit folgender Formel berechnet werden: 

Für die CPU-Leistung gilt leider keine so einfache Formel. Bei einem Medium oder Heavy User stellt im 

Allgemeinen die CPU-Leistung den begrenzenden Faktor dar. Für eine Klasse von Light Usern ist die 

maximale Benutzerzahl eher durch andere Systemressourcen begrenzt. 

Die Vielzahl an Prozessoren, mit denen jedes PRIMERGY-Modell ausgestattet werden kann, lässt bereits 

erahnen, dass es nicht eine bestimmte Anzahl Benutzer gibt, die ein PRIMERGY-Modell bedienen kann, 

sondern dass jedes PRIMERGY-Modell eine gewisse Bandbreite abdeckt. Auch gibt es keine scharfe 

Grenze, wo die Leistung eines Modells endet und die des nächst leistungsfähigeren beginnt. Vielmehr gibt 

es Überlappungen zwischen den Systemen. Die folgenden auf Basis unserer Messreihen gewonnenen 

Ergebnisse können also nur einen Eindruck für den Leistungsbereich vermitteln. 



Da die Systeme mit unterschiedlichen Lastprofilen vermessen wurden, sind keine absoluten 

Benutzeranzahlen angegeben. Vielmehr soll die relative Leistung der Systeme unter Terminal Server 

Anwendungen aufgezeigt werden. In dieser Darstellung wird die PRIMERGY RX300 S3 als Bezugssystem 

genommen und die auf dem System gemessenen Anzahl Benutzer zu 100% gesetzt. Alle anderen Systeme 

werden in Relation zum Bezugsystem angegeben, wobei die unterschiedlichen Lastprofile entsprechend 

berücksichtigt sind. 

Wenn Sie einen Terminal Server oder eine Terminal Server Farm planen, sollten Sie sich die Zeit nehmen, 

das Benutzerverhalten vorher genau zu analysieren. 

Welche Anwendungen müssen generell über den Terminal Server zur Verfügung gestellt werden? 

Welcher Benutzer nutzt wann und wie oft welche Anwendung? 

Wie intensiv wird die Anwendung verwendet? 

Welche Bildschirmauflösung und Farbtiefe verwendet der Client? 

Welches Netzwerk und Protokoll wird verwendet? 

Welche Antwortzeiten werden erwartet? 

Bei größeren Konfigurationen sollte auf eine Pilotphase unter realen Bedingungen nicht verzichtet werden. 



Analysewerkzeuge 

Bei Performance-Problemen oder auch vor der Migration von Systemen ist es hilfreich, die Terminal Server 

Umgebung zu analysieren. Je nach gewünschtem Detaillierungsgrad eignen sich verschiedene mehr oder 

weniger aufwändige Methoden, um sich einen Überblick über die aktuelle Situation zu verschaffen oder 

einen zeitlichen Ablauf der Systemauslastung aufzuzeichnen. Im Folgenden werden für die Analyse von 

Systemen nützliche Werkzeuge kurz vorgestellt. Eine ausführliche Beschreibung der Tools würde den 

Rahmen dieses Papiers sprengen. 

Task-Manager 

Am bekanntesten ist der Windows Task-Manager »taskmgr.exe«, den man 

in allen Windows Server Betriebssystemen, aber auch in Windows XP findet. 

Mit dem Task-Manager kann man sich einen schnellen Überblick über die 

aktuelle Systemauslastung verschaffen, weiterhin können laufende Anwendungen 

bzw. Prozesse und die Netzwerkauslastung angezeigt werden. Als 

Administrator kann man auch Prozesse beenden oder deren Prioritäten verändern. 

Zum Aufrufen klickt man mit der rechten Maustaste auf eine leere 

Stelle in der Taskbar und dann klickt man auf »Task-Manager«. Das Programm 

selbst stellt eine ausführliche Online-Hilfe bereit; weitere 

Informationen findet man auch bei Microsoft im Internet. Auf Terminal Server 

Systemen empfiehlt es sich, unter »Prozesse« die Einstellung »Prozesse 

aller Benutzer anzeigen« zu selektieren. Hilfreich kann auch bei 

»Systemleistung« unter »Ansicht« die Einstellung »Kernel-Zeiten anzeigen« 

sein, um den CPU-Verbrauch des Kernels einzeln zu überwachen. 

Sysinternals Process Explorer 

Detailreichere Informationen bietet das Freeware-Programm »Process 

Explorer«, das von den beiden Windows Spezialisten Mark 

Russinovich und Bryce Cogswell kostenlos unter 

www.sysinternals.com bereitgestellt wird. Es bietet eine wesentlich 

größere Funktionalität als der Windows Task-Manager. Hervorzuheben 

sind die Baumansicht der Prozesse, die gerade bei Terminal 

Server Systemen eine einfache Zuordnung von Prozessen zu 

Benutzern ermöglicht, und die erweiterte »System Information«- 

Anzeige. Der »Process Explorer« muss nicht installiert werden, kann 

aber auch an Stelle des Task-Managers in Windows integriert werden. 

Dieses Programm liefert eine Online-Hilfe mit, aber auch die 

Sysinternals-Web-Seite liefert nützliche Informationen. 

Performance Monitor 

Um den Verlauf des Ressourcenverbrauchs zu dokumentieren 

und zu speichern, sind o.g. Tools weniger geeignet. Hierzu gibt es 

in allen aktuellen Windows Versionen den System Monitor, oder 

auch Performance Monitor genannt, mit dem man über einen 

längeren Zeitraum so genannte Performance Counter beobachten 

kann. Performance Counter sind Objekt-spezifisch gruppiert, 

teilweise gibt es sie auch in verschiedenen Instanzen, wenn ein 

Objekt mehrfach vorhanden ist. Beispielsweise gibt es für das 

Objekt »Prozessor« einen Performance Counter »%Processor 

Time«, wobei dann bei einem Multiprozessorsystem eine Instanz 

pro CPU existiert. Nicht alle Performance Counter sind in 

Windows bereits vorhanden, sondern viele Anwendungen wie z.B. 

Citrix Presentation Server bringen ihre eigenen Performance 

Counter mit, die sich in das Betriebssystem integrieren und über den Performance Monitor abgefragt werden 

können. Die Performance-Daten kann man entweder am Bildschirm verfolgen oder, besser, in eine Datei 

schreiben und offline analysieren. Es können nicht nur Performance Counter des lokalen Systems 

ausgewertet werden, sondern auch von entfernten Servern, die entsprechenden Zugriffsrechte 

vorausgesetzt. Das Programm, das sich unter »perfmon.exe« aufrufen lässt, ist in der Windows Hilfe oder in 



Microsoft Artikeln im Internet beschrieben, weiterhin gibt es für jeden einzelnen Performance Counter unter 

»Erklärung« eine Erläuterung. 

Zu beachten ist, dass der Performance Monitor auch eine Windows Anwendung ist, die Rechenzeit benötigt. 

Es kann vorkommen, dass der Performance Monitor bei extremer Server-Überlastung selbst keine 

Performance-Daten ermitteln und anzeigen kann, dann sind die entsprechenden Werte 0 oder leer. 

Windows Performance Toolkit 

Mit dem Windows Performance Tools (WPT) Kit stellt Microsoft eine offizielle Sammlung von Tools zur freien 

Verfügung. Sie eignen sich zum Vermessen und Analysieren von System- und Anwendungsverhalten sowie 

des Ressourcenverbrauchs auf Windows Vista, Windows Server 2008 und späteren Windows 

Betriebssystemen. Diese Tools beruhen auf dem Event Tracing for Windows (ETW) und verursachen daher 

nur sehr geringen Overhead. Durch das ETW können Events des Kernels oder der Applikationen, wie z.B. 

Context Switches, Interrupts, Thread Creation und viele mehr, in Trace-Dateien aufgezeichnet und zu einem 

späteren Zeitpunkt ausgewertet und als übersichtliche Graphen oder Tabellen dargestellt werden. Sie 

ermöglichen daher eine sehr detaillierte Analyse eines Windows Systemverhaltens. 

Aktuell enthält die Sammlung drei Programme, die von der Kommandozeile aus ausgeführt werden können: 

Xperf 

Xperfview 

Xbootmgr 

Event tracing durchführen und auswerten 

Visionalisierung der Performance-Daten 

Erstellen eines Traces des Bootvorganges 

Die grundsätzliche Vorgehensweise erfolgt in vier Schritten: 

1) Starten des Event Tracing durch Aufruf von »xperf«; über Parameter kann genau gesteuert 

werden, was getraced werden soll. 

2) Durchführen der zu analysierenden Szenerie. 

3) Stoppen des Event Tracing durch Aufruf von »xperf«; alle zur Analyse notwendigen Daten 

werden ins Trace-File geschrieben. 

4) Auswerten des Trace-Files mittels »xperf« oder auch Visionalisierung über »xperfview«; kann 

auch auf einer anderen Maschine erfolgen. 

Beispiel eines Xperfview-Graph für CPU-Sampling: 



Beispiel eines Xperfview-Graph für Disk IO Sampling: 

Das Windows Performance Tool Kit ermöglicht eine sehr viel mehr in die Tiefe gehende Analyse eines 

Systemverhaltens als der Performance Monitor. Dadurch, dass die Aufzeichnung der Events über einen 

längeren Zeitraum oder auf einem durch viele Prozesse stark belasteten System zu sehr großen Trace Files 

führt, ist dieses Tool aber eher für die Analyse einer Momentaufnahme geeignet, während z.B. der 

Performance Monitor zur Analyse eines Systemverhalten über einen längeren Zeitraum, z.B. einen Tag oder 

eine Nacht eingesetzt werden kann. 

Windows Performance Analyzer kann nur eingeschränkt auf Windows XP bzw. Windows Server 2003 

eingesetzt werden. Es können zwar auch Event Traces geschrieben werden, allerdings müssen alle 

Analysen, die Trace-Dekodierung enthalten – das beinhaltet auch die graphische Aufbereitung mittels 

»Xperfview« – auf einem Windows Vista bzw. Windows Server 2008 System erfolgen. 



Citrix Resource Manager 

In größeren Terminal Server Konfigurationen 

mit Citrix Presentation Server Enterprise 

Edition kommt vielleicht auch der Resource 

Manager von Citrix zum Einsatz. Er bietet 

eine benutzerfreundlichere Sicht auf die für 

den Citrix Presentation Server relevanten 

Performance Counter und darüber hinaus 

noch eine Schwellwertüberwachung mit Benachrichtigung 

des Administrators. Die 

Schwellwerte sind schon auf bestimmte 

Werte voreingestellt, können aber bei Bedarf 

angepasst werden. Da diese Schwellwerte in 

der Citrix Resource Manager Software fest 

eingestellt sind, ist es fraglich, ob sie der 

Vielzahl der heute verfügbaren Leistungsvarianten 

von Server-Systemen ohne individuelle 

Anpassung gerecht werden können. 

Auf einem Citrix Presentation Server 4.0 Terminal Server unter Windows Server 2003 Enterprise Edition 32- 

bit mit 16 GB Hauptspeicher und Gigabit LAN sind beispielsweise folgende Werte voreingestellt: 

Objekt Counter Warnung Fehler 

Citrix MetaFrame 

Presentation Server 

Data Store Connection 

Failure 6 60 

Logical Disk % Disk Time 400 600 

Logical Disk % Free Space 10 5 

Memory Available Bytes 858924851 343569940 

Memory Pages/sec 3000 5000 

Network Interface Bytes Total/sec 3000000 4000000 

Paging File % Usage 40 50 

Processor % Interrupt Time 0.3 0.4 

Processor % Processor Time 80 90 

System Context Switches/sec 120000 14000 

Terminal Services Active Sessions 50 100 

Terminal Services Inactive Sessions 10 20 

Wenn die Schwellwerte jedoch auf den Normalbetrieb (Baseline) eines Citrix Systems angepasst werden, 

dann lösen Überschreitungen rechtzeitig eine Warnung oder einen Alarm aus und helfen dem Administrator, 

einen Engpass frühzeitig zu erkennen. Für den Citrix Resource Manager sei auf die Dokumentation von 

Citrix verwiesen. 



Microsoft Operations Manager (MOM) 2005 

Microsoft stellt mit dem Produkt 

Microsoft Operations Manager 

(MOM) 2005 eine leistungsfähige 

Software zur Verfügung, mit der 

Ereignisse und Systemleistung 

verschiedener Server-Gruppen im 

Firmennetzwerk überwacht werden 

können. MOM bietet proaktive 

Benachrichtigungen im Warnungs- 

und Fehlerfall und erstellt 

Berichte und Trendanalysen. 

MOM bedient sich dabei existierenden 

Windows Mitteln wie der 

Ereignisanzeige, liest die Performance 

Counter aus und überwacht 

Dienste, jedoch komfortabel 

für ganze Gruppen von Servern. 

Die Ergebnisse werden in einer SQL Datenbank gespeichert. 

Zusätzliche Management Packs für MOM werden von Microsoft und anderen Anbietern für ihre Produkte zur 

Verfügung gestellt und hinterlegen weitere System- oder Anwendungs-spezifische Regelwerke in der MOM- 

Datenbank. So kann MOM nicht nur Terminal Server, sondern eine Vielzahl von verschiedenen Server- 

Typen gleichzeitig überwachen. 

Für die Terminal Services kann das »Microsoft Terminal Server MOM 2005 Management Pack« hinzugefügt 

werden, das Terminal Server-spezifische Regeln und Berichte für die folgenden Komponenten mitbringt 

Terminal Services 

Terminal Services Licensing Server 

Session Directory Server 

sowie ein Performance Monitoring anbietet. 

Beispielsweise wird eine Warnung ausgegeben, wenn mehr als 520 Terminal Server Sessions aktiv sind 

oder die Prozessorauslastung einer Session über einen Zeitraum von 15 Minuten über 80% liegt. Ein Fehler 

wird angezeigt, wenn mehr als 20 Terminal Server Sitzungen inaktiv sind oder die Cachetrefferrate weniger 

als 99% beträgt. Diese vordefinierten Regeln müssen an die kundenspezifischen Gegebenheiten angepasst 

werden. 

Weiterhin können aktive und inaktive Sitzungen über gewisse Zeiträume beobachtet werden, so dass hieraus 

Aussagen über das Benutzerverhalten gewonnen werden können. 

Eine Beschreibung der Features von MOM würde den Rahmen dieses Dokumentes sprengen. Zu MOM und 

den einzelnen Management Packs gibt es im Internet detaillierte Beschreibungen von Microsoft. 



Engpassanalyse 

Um eine Vorhersage zu treffen, wie sich eine existierende Terminal Server Umgebung verhält oder um bei 

einer Pilotinstallation die Auslastung eines Terminal Servers beurteilen zu können, ist es notwendig, selbst 

eine Engpassanalyse durchzuführen oder durch unseren Professional Service durchführen zu lassen. 

Performance-Werte aufzuzeichnen oder zu überwachen ist weniger das Problem, als die richtigen Schlüsse 

aus den Messwerten zu ziehen. Bevor wir im Folgenden einige wichtige Performance Counter zu den 

verschiedenen Performance-relevanten Server-Objekten diskutieren, werden kurz einige typische 

Verhaltensweisen von Performance Countern dargestellt. Wenn man einen Engpass auf einem Server- 

System analysiert, ist es nicht einfach, aus einem Schnappschuss von der Engpasssituation Rückschlüsse 

zu ziehen. Von Vorteil ist es, wenn man Erfahrungen hat, wie sich das Server-System unter verschiedenen 

Lasten verhält und eine Baseline zum Vergleich erstellt hat. 

Während man einige Messwerte wie den Netzwerkdurchsatz in Relation zum theoretisch erreichbaren 

Maximalwert, z.B. bei einer 100 MBit-Netzwerkverbindung, setzen kann, ist dies bei anderen Messwerten, 

wie z.B. Anzahl Context Switches pro Sekunde, nicht möglich. 

Es gibt folgende typische Kurvenverläufe bei synthetischer Last: 

Linear: 

Konstant: 

Die Performance-Werte steigen im gleichen 

Verhältnis zur Last. Kein Engpass. 

Logarithmisch: 

Die Performance Counter sind nicht abhängig von 

der Last, sondern konstant. Eventuell bilden sich 

bei unterschiedlicher Last verschiedene Stufen 

einer Treppenfunktion aus. 

Exponentiell: 

Bei steigender Last steigen die Performance 

Counter nicht weiter, sondern erreichen eine 

Sättigung. Dies kann ein Indiz für einen Engpass 

sein. 

Im unteren Lastbereich steigt die Kurve relativ 

flach an, während sie bei steigender Last 

überproportional wächst. Im Extremfall kann hier 

bereits ein weiterer Benutzer das »Fass zum 

Überlaufen« bringen. 

Im Folgenden werden einzelne Performance Counter, nach Systemkomponenten gruppiert, beschrieben und 

diskutiert. Im Anschluss daran ist ein Beispielskript eingefügt, das nach geringen Anpassungen direkt für ein 

Terminal Server System übernommen werden kann. 



Rechenleistung/System 

Die wichtigsten Performance Counter sind: 

\Processor(*)\% Processor Time bzw. \Processor(_Total)\% Processor Time 

\System\Processor Queue Length 

»% Processor Time« ist die insgesamt verbrauchte Rechenzeit. Auf jedem Windows System läuft ein 

»Leerlaufprozess«, den man mit dem Task-Manager oder Process Explorer auch sehen kann. Alle CPU Zeit, 

die dieser idle Prozess nicht bekommt, ist »% Processor Time«. Bei »% Processor Time« gibt es mehrere 

Instanzen, eine pro logische CPU, die Windows kennt. Unsere unten aufgeführte Beispielkonfiguration 

zeichnet mit dem Objekt »Processor(*)« alle vorhandenen Prozessoren auf und deren Summe. Die 

Auslastung der einzelnen Prozessoren muss nicht immer gleich hoch sein, gerade im Niedriglastbereich und 

mit Hyper-Threading ist das oft der Fall. Weiterhin wird beim normalen Arbeiten mit Terminal Server 

Anwendungen selten eine in Summe 100%ige CPU-Auslastung erreicht. Je mehr logische Prozessoren 

parallel arbeiten, desto niedriger kann sich der Durchschnittswert der CPU-Auslastung darstellen, auch wenn 

der Terminal Server bereits überlastet ist. 

»Processor Queue Length« bezeichnet die Anzahl Threads, die auf ihre Ausführung warten. Dieser 

Counter ist nur einmal pro System vorhanden, also nicht CPU-spezifisch. Daher sollte dieser Wert die 

Anzahl der Prozessoren nicht dauerhaft übersteigen. 

Normalerweise steigen »% Processor Time« und 

»Processor Queue Length« (PQL) bei Belastung 

des Servers gemeinsam an. Nebenstehende Grafik 

zeigt einen typischen Verlauf der CPU Zeit und der 

»Processor Queue Length«, während die Last auf 

dem Terminal Server zunehmend gesteigert wird. 

Kritisch sind % CPU-Zeiten ab 80% zusammen mit 

hohen Peaks der PQL-Kurve, die dann auch 

dauerhaft auf einem höheren Niveau bleibt. 

Es kann jedoch auch Situationen geben, wo eine 

Vielzahl von kleinen Prozessen auf ihre Ausführung 

wartet und das System allein schon durch die 

Verwaltung der Prozesse überlastet wird, obwohl 

die benötigten CPU-Ressourcen noch verfügbar wären. 

Zusätzliche Performance Counter: 

\System\Context Switches/sec 

\System\System Calls/sec 

\System\Processes 

\Processor(*)\Interrupts/sec bzw. \Processor(_Total)\Interrupts/sec 

»System Calls/sec« zählt die Anzahl Aufrufe an das System pro Sekunde. »Context Switches/sec« zählt 

die Anzahl Kontextwechsel pro Sekunde, also Wechsel zwischen Threads oder zwischen 

Benutzerprogrammen und Kernel-Aktivitäten. »Processes« ist die Anzahl der aktuell ausgeführten 

Prozesse. »Interrupts/sec« ist ein Counter, den es pro Prozessorinstanz und als Durchschnitt aller 

Prozessoren gibt. Interrupts sind meist durch Hardware wie Netzwerkkarten, Tastatur, Maus, Systemuhr, 

usw. initiierte Ereignisse, die der Prozessor bearbeiten muss. Zu beachten ist, dass das Windows in der x64 

Edition deutlich höhere Werte bei Interrupts/sec anzeigt als das 32-bit Windows. Dieser Unterschied liegt 

allerdings einzig in der Zählung der Interrupts, da das 64-bit Windows auch die Interrupt-Weiterleitungen 

zwischen den Prozessoren dokumentiert, die unter dem 32-bit Windows nicht mitgezählt wurden. 

Diese Counter steigen normalerweise zusammen mit der benötigten Rechenleistung an. Bedenklich ist es, 

wenn diese Kurven eine Sättigung erreichen, was bedeutet, dass das System nicht mehr von diesen 

Ereignissen verarbeiten kann. Eine Sättigung kann am besten über einen längeren Zeitraum beurteilt 

werden, im Zusammenhang mit den anderen Performance Countern. Die Anzahl Benutzer steigt deutlich 

steiler als der aufgezeichnete Performance Counter. 

Ein CPU-Engpass kann auch durch fehlerhafte Anwendungen ausgelöst werden, siehe Kapitel 

Applikationen. 



Arbeitsspeicher 

Die wichtigsten Performance Counter 

bzgl. der Arbeitsspeicherauslastung 

sind: 

\Memory\Available MBytes 

\Memory\Pages Input/sec 

\Process(_Total)\Working Set 

»Available MBytes« ist der aktuell 

freie physikalische Hauptspeicher in 

MB. »Pages Input/sec« zeigt die 

Anzahl der Seiteneinlagerungen pro 

Sekunde. Der »Working Set« einer 

Anwendung ist der Speicher, den sie 

bereits verwendet hat. 

Nebenstehende Performance- 

Aufzeichnung wurde auf einem 

PRIMERGY Server erstellt, der 

absichtlich in einen Hauptspeicherengpass 

getrieben wurde. Eine 

Eigenschaft des Windows Betriebssystems ist hierbei zu erkennen: wenn genügend Hauptspeicher zur 

Verfügung steht, wird auch mehr Speicher belegt. Erst wenn der freie Speicher unter einen bestimmten 

Schwellwert fällt, wird »aufgeräumt« und der Speicher außerhalb des »Working Set« ausgelagert. So kann 

man an einem System, das nicht im Speichergrenzbereich betrieben wird, den wirklichen Speicherbedarf 

nicht unbedingt ablesen. In der hier provozierten Engpasssituation werden jedoch exzessive Paging- 

Aktivitäten sichtbar. Der Speicherengpass deutet sich bereits an, wenn »Available MBytes« unter einen 

Schwellwert fällt und Windows deshalb den »Working Set« verkleinert. Gleichzeitig steigen die Paging- 

Aktivitäten (»Pages Input/sec«) an. Wenn nun noch weiterer Speicher gebraucht wird, dann wird schrittweise 

der »Working Set« weiter verkleinert und die Paging-Vorgänge steigen deutlich an. Auch der Performance 

Counter »Paging File\%Usage« steigt entsprechend an. 

Auch die folgenden Performance Counter können weiteren Aufschluss über die Auslastung des Arbeitsspeichers 

geben: 

\Memory\Committed Bytes 

\Memory\Pages Output/sec 

\Memory\Pages Faults/sec 

\Paging File(\??\C:\pagefile.sys)\% Usage 

In »Committed Bytes« wird angegeben, wie viel virtueller Hauptspeicher den laufenden Anwendungen 

zugesagt und im Pagefile reserviert wurde. Hieran kann man ablesen, ob das System in einen Engpass mit 

dem virtuellen Adressraum gerät. 

»Pages Output/sec« zeigt die Anzahl der Seitenauslagerungen pro Sekunde, durch die physikalischer 

Hauptspeicher freigegeben wird, indem die Daten auf die Festplatte geschrieben werden. Auch wenn 

ausreichend Arbeitsspeicher vorhanden ist, findet eine moderate Zahl von Auslagerung statt. Erst wenn 

dieser Wert sprunghaft ansteigt, liegt ein Speicherengpass vor. Insbesondere ist darauf zu achten, dass 

dieser Wert mit der Leistungsfähigkeit der Festplatte harmoniert, auf der das Pagefile liegt. 

»Pages Faults/sec« ist ein Durchschnittswert der Seitenfehler pro Sekunde, beinhaltet aber sowohl 

Seiteneinlagerungen aus dem physikalischen Hauptspeicher (»soft fault«) als auch Zugriffe auf die 

Festplatte (»hard fault«). 

»Paging File\%Usage« des Pagefiles ist dessen Belegung in Prozent. Eine geringe Belegung des Pagefiles 

ist normal, auch wenn genügend RAM vorhanden ist. Wenn diese jedoch signifikant ansteigt, könnte ein 

Hauptspeicherengpass vorliegen. Dies wird durch die anderen Performance Counter der Paging-Aktivitäten 

untermauert. 

Ein Engpass des Arbeitsspeichers geht direkt Hand in Hand mit einem Ansteigen der Disk Counter auf der 

Festplatte, die das Pagefile beherbergt (siehe Kapitel Engpassanalyse - Disk-Subsystem). 



Betriebssystemressourcen 

Der wichtigste Performance Counter, an dem man die Gesundheit des Betriebssystems ablesen kann, ist: 

\Cache\Copy Read Hits % 

»Copy Read Hits %« ist der prozentuale Anteil der erfolgreichen Lesevorgänge aus dem Systemcache. 

Werden Daten im Systemcache gefunden, so erübrigt sich ein Festplattenzugriff, was in einem enormen 

Performance-Gewinn resultiert. Laut Microsoft sollte dieser Anteil immer über 95% liegen. Allerdings kann 

sich bei diesem Performance Counter bereits eine Verschlechterung von wenigen Prozentpunkten durch 

eine verzögerte Reaktion des Terminal Servers bemerkbar machen. Im Idealfall liegt »Copy Read Hits %« 

während des eingeschwungenen Server-Betriebs über 99%. Ein 32-bit-Betriebssystem hat im Vergleich zum 

64-bit-Betriebssystem durch den limitierten Kernel-Adressraum auch einen kleineren Systemcache. 

Da speziell Engpässe des Betriebssystems im Terminal Server Umfeld untersucht werden, sollten folgende 

zusätzliche Performance Counter auf jeden Fall mit betrachtet werden: 

\Memory\Free System Page Table Entries 

\Memory\Pool Nonpaged Bytes 

\Memory\Pool Paged Bytes 

»Free System Page Table Entries« zeigt die Anzahl der freien Einträge in der System Page Table. Ein 

Engpass dieser Betriebssystemressource ist erreicht, wenn nur noch wenige 1000 Einträge frei sind. »Pool 

Nonpaged Bytes« ist die Anzahl Bytes, die aktuell für den Nonpaged Pool verwendet werden. Im Nonpaged 

Pool speichert das Betriebssystem alle Daten, die immer im Hauptspeicher gehalten werden müssen und 

nicht in das Pagefile geschrieben werden dürfen. »Pool Paged Bytes« ist die Anzahl Bytes, die aktuell für 

den Paged Pool verwendet werden. Im Paged Pool liegen die Systemspeicherbereiche, die in das Pagefile 

ausgelagert werden können. Auf Windows Server 2003 32-bit-Betriebssystemen sind diese 

Speicherbereiche limitiert und nicht erweiterbar, so dass diese an ihre Grenzen stoßen können, wenn viele 

Benutzer auf dem Terminal Server arbeiten. Ein größerer Speicherausbau führt nicht zu größeren Kernel- 

Strukturen, sondern es wird im Gegenteil noch mehr Kernel-Speicher durch die Verwaltung und die 

Adressierung dieser Datenbereiche belegt. 

Nebenstehende Grafik zeigt eine solche 

Situation, bei der bei einem Terminal 

Server ein Engpass der Betriebssystemressourcen 

durch kontinuierliche 

 

Erhöhung der Benutzerlast provoziert 

 

wurde. Zur Verdeutlichung wird 

zusätzlich der Performance Counter 

»Working Set« dargestellt. Man erkennt 

vier Phasen bei der Server-Belastung. In 

 

der ersten Phase ist der Terminal Server 

performant, die Trefferrate im 

Systemcache liegt fast bei 100% , es 

sind noch genug freie PTEs 

 

vorhanden und der Working Set sowie 

der Paged Pool und der Nonpaged 

Pool kann mit der Anzahl Benutzer 

 

gesteigert werden. In der zweiten Phase 

fällt die Trefferrate des Systemcaches 

ab. Der Paged Pool erfährt eine 

Sättigung. Die Performance wird sich 

langsam verschlechtern. In der dritten Phase ist die Effizienz des Systemcaches deutlich herabgesetzt. 

während durch Paging-Aktivitäten noch Paged Pool Ressourcen freigeschaufelt werden konnten. Die 

Terminal Server Performance wird durch fehlende Kapazitäten im Systemcache gemeinsam mit erhöhten 

Plattenaktivitäten jedoch nicht mehr befriedigend sein. Überlastet man das System über diese Phase hinaus, 

dann erkennt man die Sättigung des Paged Pools. Auch der »Working Set« kann nicht mehr gesteigert 

werden und die freien PTEs sind auf einem Minimalwert angekommen. Neben einer schlechten Terminal 

Server Performance wird sich ein Teil der Benutzer auch nicht mehr anmelden können, oder Anwendungen 

können nicht mehr gestartet oder bedient werden. Das System hat, im Gegensatz zu dem im Abschnitt 

Arbeitsspeicher gezeigten Fall eines Hauptspeicherengpasses, jedoch noch genügend freien physikalischen 

Speicher. In diesem Fall hatte das System am Ende der Aufzeichnung noch 26 GB von 32 GB 

physikalischem Hauptspeicher frei. 



Disk-Subsystem 

Der wichtigste Performance Counter zur 

Beurteilung der Festplattenauslastung ist: 

\PhysicalDisk(*)\Avg. Disk Queue Length 

bzw. 

\LogicalDisk(*)\Avg. Disk Queue Length 

Hierbei zeichnen die Performance Counter für die 

»PhysicalDisk« alle Aktivitäten an einem 

physikalischen Laufwerk auf, während das 

»LogicalDisk« Objekt diese nach den einzelnen 

Partitionen, z.B. C: oder D:, unterteilt. Wird ein 

RAID-Controller, SAN oder iSCSI verwendet, so 

bezieht sich der Counter »PhysicalDisk« jedoch 

nicht, wie der Name suggeriert, auf die physikalische Platte, sondern auf den RAID-Verband bzw. die LUN. 

Der Counter »Avg. Disk Queue Length« ist der Durchschnitt der Festplattenwarteschlange für Lese- und 

Schreibaufträge, man kann aber auch für Lese- und Schreiboperationen getrennte Counter aktivieren. 

Dieser Performance Counter ist ein signifikanter Indikator für die Belastung des Disk-Subsystems und sollte 

nicht dauerhaft größer sein als 1 pro Festplatte, die netto zur Verfügung steht. In einem RAID 1 Verband aus 

zwei Festplatten also nicht dauerhaft größer als 1, in einem RAID 1+0 aus 6 Festplatten nicht dauerhaft 

größer als 3. Die Beispielgrafik zeigt die »Avg. Disk Queue Length« für eine Konfiguration mit einer 

Festplatte, bei der der Wert unter 1 liegen sollte. Während im ersten Zeitraum dieser Aufzeichnung die 

Festplatte nicht wesentlich belastet wird, so ist gegen Ende der Messung das Disk-Subsystem deutlich 

überlastet. 

Die Performance des Disk-Subsystems, auf dem das Pagefile liegt, sollte immer gemeinsam mit dem 

Arbeitsspeicher betrachtet werden. Wenn der Arbeitsspeicher knapp wird, lagert Windows Teile des 

Speichers in das Pagefile auf der Festplatte aus und liest diese später wieder ein, was zu deutlich erhöhten 

Plattenaktivitäten auf der Festplatte führt, auf der das Pagefile liegt. 

Zusätzliche Performance Counter des \PhysicalDisk(*) bzw. \LogicalDisk(*) Objektes, die weiteren 

Aufschluss über die Plattenaktivität geben können: 

Avg. Disk Bytes/Read 

Durchschnitt der Auftragsgröße beim Lesen 

Avg. Disk Bytes/Write 

Durchschnitt der Auftragsgröße beim Schreiben 

Avg. Disk sec/Read 

Durchschnittswert der pro Leseauftrag benötigte Zeit in Sekunden 

Avg. Disk sec/Write 

Durchschnittswert der pro Schreibauftrag benötigte Zeit in Sekunden 

Disk Read Bytes/sec 

Gesamtanzahl der gelesenen Bytes pro Sekunde 

Disk Reads/sec 

Gesamtanzahl der Lesevorgänge pro Sekunde 

Disk Write Bytes/sec 

Gesamtanzahl der geschriebenen Bytes pro Sekunde 

Disk Writes/sec 

Gesamtanzahl der Schreibvorgänge pro Sekunde 

Der vielfach verwendete Counter »% Disk Time« ist nicht zu empfehlen, da er in heutigen Windows 

Versionen genau dem Hundertfachen von »Avg. Disk Queue Length« entspricht. 



Aus diesen Performance Countern lässt sich das Zugriffsmuster auf die Festplatten ablesen, d.h. die 

gelesenen und geschriebenen Blockgrößen, und die Latenzzeiten (»Avg. Disk sec«) beim Lesen und 

Schreiben. Diese Messwerte sollten in dem Fall als Zusatzinformation ausgewertet werden, wenn die »Avg. 

Disk Queue Length« auf einen Festplattenengpass hindeutet. Mit der Anzahl von Schreib- und 

Leseaufträgen pro Sekunde können in Verbindung mit der im Durchschnitt genutzten Auftragsgröße und 

dem verwendeten RAID-Level ebenfalls Rückschlüsse auf die Auslastung des Disk-Subsystems getroffen 

werden. Zum Sizing von Disk-Subsystemen wurde ein eigenes White Paper »Performance Report – Modular 

RAID für PRIMERGY« [L5] erstellt. 

Zu beachten ist auch, dass ein Disk-Subsystem, das über iSCSI angeschlossen ist, zusätzlich zu den 

Performance Countern der Festplattenobjekte bei den Performance Countern der Netzwerkkarte auftaucht, 

die im Folgenden beschrieben werden. 

Netzwerk 

Für einen ersten Blick auf die Netzwerkauslastung reicht der Task-Manager aus. Auf der Seite »Netzwerk« 

(»Networking«) erhält man schnell einen Überblick über die »Netzwerkauslastung« (»Network Utilization«) 

der einzelnen Netzwerkkarten und deren »Übertragungsrate« (»Link Speed«). 

Bei einer Performance Monitor-Aufzeichnung sollten die folgenden Performance Counter mit berücksichtigt 

werden: 

\Network Interface(*)\Bytes Sent/sec 

\Network Interface(*)\Bytes Received/sec 

»Bytes Sent/sec« und »Bytes Received/sec« zählen die aus Sicht des Servers gesendeten und 

empfangenen Daten in Bytes. 

Zusätzlich ist es auch sinnvoll die Performance Counter 

\Network Interface(*)\Packets Received/sec 

\Network Interface(*)\Packets Sent/sec 

zu betrachten. »Packets Sent/sec« und »Packets Received/sec« sind die Anzahl der aus Sicht des 

Servers gesendeten und empfangenen Datenpakete. Aus dem Verhältnis der Datenbytes und der Anzahl 

der Pakete lässt sich die durchschnittliche Paketgröße ermitteln. 

Je größer die Netzwerkpakete, desto höher die mögliche Netzwerkauslastung. 

Die Protokolle RDP oder ICA, die ein Terminal Server zwischen Client und Server verwendet, beinhalten 

nicht sehr große Datenpakete. Eine 100% Auslastung eines 100 MBit-Netzwerkes wird sich daher kaum 

beobachten lassen. Das ICA-Protokoll des Citrix Presentation Server ist dabei noch etwas sparsamer als 

das RDP-Protokoll des Microsoft Terminal Services. 

Neben der Client-Server-Kommunikation entsteht in den meisten Anwendungsszenarien jedoch auch 

weiterer Netzwerkverkehr zu Back-End-Server, ins Internet, oder bei Verwendung eines Netzwerk-basierten 

Disk-Subsystem, wie NAS oder iSCSI Datentransfer zum Disk-Subsystem. Es ist dringend zu empfehlen, 

dass für diese unterschiedlichen Datenströme dedizierte Netzwerkinterfaces verwendet werden. 

Die verschiedenen Netzwerkinterfaces können anstelle des (*) im Performance Monitor auch einzeln mit 

ihrem Namen selektiert werden. Wenn (*), wie im Beispiel oben, als Netzwerkkartenbezeichnung angegeben 

wird, dann werden alle im System verfügbaren Netzwerkkarten aufgezeichnet. Hierzu gehört auch das 

Loopback-Interface, auf dem normalerweise nicht viel Netzwerkverkehr stattfindet. 

Zu beachten ist, dass sich mit dem Performance Monitor oder dem Task-Manager nur die Auslastung des 

Netzwerkes aus Sicht des Terminal Servers analysieren lässt. Datenverkehr anderer Server und Clients auf 

dem Netzwerk kann nicht erfasst werden. Oft ist jedoch nicht das Server-seitige Netzwerk selbst zu klein 

dimensioniert, sondern die Probleme können beispielsweise von fehlerhaften oder falsch konfigurierten 

Komponenten herrühren oder durch vielfältige Problemen bei der Verbindung dieser Komponenten 

entstehen. An dieser Stelle sollte man einen Netzwerkspezialisten hinzuziehen. 




Der Microsoft Terminal Server selbst liefert nicht viele Performance Counter. Jedoch bietet der Terminal 

Server unter dem Objekt »Terminal Services Sessions« Performance Counter pro Session für eine 

detaillierter Auswertung einzelner Sitzungen an. 

Die Anzahl Terminal Server Verbindungen sollte immer mitgeschrieben werden, um die anderen 

Performance Counter in Relation zur Anzahl verbundenen Benutzer setzen zu können: 

\Terminal Services\Active Sessions 

Es ist ein Unterschied, ob der Benutzer die Verbindung zum Terminal Server beendet, indem er sich 

abmeldet (»Logoff«) oder ob er mit einem »Disconnect« die Verbindung nur unterbricht. Im letzteren Fall 

läuft die Anwendung auf dem Terminal Server weiter und gibt ihre Ressourcen nicht frei. Der Benutzer kann 

seine Arbeit dann an dieser Stelle fortsetzen. Manche Anwendungen brauchen auch CPU-Ressourcen, 

während die Verbindung getrennt ist. Daher sollte die Anzahl der inaktiven Verbindungen (»Inactive 

Sessions«) 

\Terminal Services\Inactive Sessions 

ebenfalls mitprotokolliert werden. 

Diese beiden Parameter gelten gleichwohl für die Microsoft Terminal Services als auch für den Citrix 

Presentation Server. 

Citrix selbst liefert auch Performance-Objekte mit verschiedenen Performance Countern mit. Folgende 

Performance Objekte werden installiert: 

»Citrix CPU Utilization Mgmt User« 

Counter für das Feature »CPU Utilization Management« 

»Citrix IMA Networking« 

Counter für Anzahl Verbindungen und Netzwerklast 

»Citrix MetaFrame Presentation Server« 

Counter u.a. für Data Store, Local Host Cache, Licensing 

»ICA Session« (für einzelne Sessions oder gesamt »_Server Total«) 

Counter spezifisch für ICA-Session 

Diese sind jedoch eher für spezielle Auswertungen geeignet und weniger für eine allgemeine Performance- 

Analyse eines Terminal Servers. 



Applikationen 

Eine fehlerhafte Anwendung kann eine CPU zeitweise oder permanent voll belasten, und gerade auf einem 

Terminal Server kann das fatale Auswirkungen auf die Gesamtleistung des Systems haben, da diese 

Anwendung auch mehrfach gestartet sein kann. Wenn die Anwendung einen Thread besitzt, der z.B. in einer 

Endlosschleife läuft oder »aktiv wartet«, dann belegt dieser maximal »100% / #CPUs« Prozessorzeit. Auf 

einem System mit zwei logischen Prozessoren also 50%, auf einem System mit vier logischen CPUs 25%. 

Je mehr logische CPUs das System hat, desto weniger fällt so ein Programm auf. Bei CPU-Engpässen sollte 

immer überprüft werden, ob es solche Anwendungen gibt, die dauerhaft genau diese Prozentzahl an CPU- 

Leistung benötigen. Kurzfristige Lastspitzen einer Anwendung sind hingegen völlig normal. Einen ersten 

Blick auf die Anwendungen ermöglicht der Task-Manager bzw. der Process Explorer. Folgender Screenshot 

zeigt einen synthetischen Lastsimulator auf einem PRIMERGY System mit acht logischen Prozessoren, der 

eine Endlosschleife simuliert. Der Process Explorer weist 12.50% CPU Last aus, d.h. diese eine Anwendung 

lastet einen Prozessorkern vollständig aus. 

Ein solches Verhalten ist oft in Desktop-Anwendungen zu finden, die für einen einzelnen Benutzer geschrieben 

und daher für eine Terminal Server Umgebung nur bedingt geeignet sind. Wenn Citrix Presentation 

Server 4.0 eingesetzt wird, dann kann man solche Anwendungen auch in ihrer Rechenleistung beschränken. 

Diese Einschränkung greift nur, wenn insgesamt zu wenig CPU Ressourcen zur Verfügung stehen. 

Auch der Speicherbedarf einer Applikation sollte überprüft werden. Unser synthetischer Lastsimulator hat ca. 

1.5 GB virtuellen Speicher belegt, allerdings ist der »Working Set« nur 5.3 MB groß. Diese Anwendung hat 

zwar eine Menge Speicher reserviert, hat ihn jedoch nicht in Verwendung. Erst wenn die Anwendung auf 

dem Speicher arbeitet, vergrößert sich der »Working Set« und der im System verfügbare Speicher 

»Available Mbytes« nimmt ab. 

Mit dem Performance Monitor kann man viele Performance Counter statt für das Gesamtsystem auch für 

einzelne laufende Anwendungen anzeigen lassen. Hierzu verwendet man das Objekt »Process« und als 

Instanz dann den zu überwachenden Prozess. 



Performance Monitor-Konfigurationsskript 

An dieser Stelle möchten wir eine Beispielkonfiguration mit den aussagekräftigsten Performance Countern 

aufführen, die bei Bedarf erweitert werden kann. Normalerweise stellt man die Auswahl der Performance 

Counter mit dem Performance Montitor Programm zusammen und speichert diese dann als »Protokolle der 

Ablaufverfolgung (Counter Log)« als *.htm Datei ab. Diese HTML-Datei kann man auch wieder in einer 

anderen Umgebung einlesen, jedoch sind einige Parameter ggf. systemspezifisch einzustellen, und die 

Performance Counter sind neu zu nummerieren, wenn Performance Counter hinzugefügt oder entfernt 

werden. 

Beim remote Monitoring ist 

der Name des Servers im 

Format »\\« vor den 

Performance Counter zu 

stellen, z.B. für den Server 

»server«: »\\server\Terminal 

Services\Active Sessions«. 

Neben einem einzelnen 

Server können beim remote 

Monitoring auch mehrere 

Server gleichzeitig überwacht 

werden. 

Alternativ kann man die Konfiguration 

der Performance 

Counter auch in eine Textdatei 

schreiben und mit dem 

»logman« Kommando laden. 

Hierzu siehe die Hilfe des 

»logman« Kommandos mit 

»logman -?«. 

Ein fertiges Konfigurationsskript 

ist nebenstehend abgebildet. 

Es kann als HTML- 

Datei, z.B. mit dem Namen 

»perf.htm«, am besten mit 

einem Text-Editor wie Notepad, 

angelegt werden und 

dann im Performance 

Monitor mit »Neue Protokolleinstellungen 

von... (New 

Log Settings From ...)« importiert 

werden. Besonders 

wichtige Parameter sind farblich 

unterlegt, während der 

fett gedruckte Laufwerksbuchstabe 

ggf. an den 

Speicherort des Pagefiles 

angepasst werden muss. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Messwerkzeuge 

Da es für Terminal Server keinen Standard-Benchmark gibt, existiert eine Reihe von verschiedenen 

proprietären Messwerkzeugen und -methoden zur Skalierung von Terminal Servern. Neben Fujitsu 

Technology Solutions benutzen auch Microsoft und Citrix eigene Software und auch der bekannte Microsoft- 

Press-Autor und Terminal Server Experte Dr. Bernhard Tritsch hat Untersuchungen mit eigenem 

Lastsimulator durchgeführt. Die 2002 gegründete Firma LoginConsultants stellt auf ihren Internet-Seiten ein 

kostenloses Tool zum Messen von Server-based Computing Sessions zur Verfügung. 

Die nachfolgende Tabelle charakterisiert die verschiedenen Werkzeuge. 

Microsoft 



Scalability 

Planning Tool 

Citrix 

CSTK / 

Citrix ICAMark 

3.0 

Fujitsu 

Technology 

Solutions 

T4US 

visionapp 

Remote 

Desktop + 

vRD Load 

Edition 

Login 

Consultants 

Login Virtual 

Session 

Indexer (VSI) 

Eine Lastsimulator-Suite von Microsoft (http://www.microsoft.com), die Bestandteil des 

Windows Server 2003 Resource Kit ist. 

Arbeitet nur mit Microsoft Terminal Services (RDP-Protokoll) 

bis zu 20 Benutzer pro Lastgenerator 

Knowledge Worker arbeitet mit einem Remote Desktop und verschiedenen 

Anwendungen (Microsoft Excel, Outlook, Internet Explorer, Word) 

Eingaben per Tastatur, 35 Wörter pro Minute 

Aufzeichnung von Performance Countern mit dem Windows Performance Monitor 

CSTK ist ein Lastsimulator von Citrix (http://www.citrix.com/cdn). 

Citrix ICAMark 3.0 ist ein Citrix-internes Tool, das auf dem CSTK basiert. 

Nur für Citrix Presentation Server / XenApp (ICA-Protokoll). 

Produziert Last, aber ermittelt keine Antwortzeiten von einzelnen Aktionen, nur die 

Gesamtlaufzeit für ein komplettes Skript ist messbar. 

Light User: Microsoft Excel, ca. 20 Wörter pro Minute 

Heavy User: Microsoft Excel, Microsoft Access, Microsoft PowerPoint (sequentiell) 

ca. 40 Wörter pro Minute 


Eigenentwicklung von Fujitsu Technology Solutions 

Sowohl für Microsoft Terminal Services als auch für Citrix Presentation Server 

Bis zu 40 Benutzer pro Lastgenerator 

Überwachung der Antwortzeiten für alle Benutzer bei verschiedenen Aktionen, Vergleich 

mit Referenzmessung 

Medium Lastprofil: 

Login + Desktop + Office-Anwendungen + Logoff 

Eingabe per Tastatur und Maus; Lesen und Schreiben von Daten 


Eigenentwicklung von visionapp (http://www.visionapp.com/de) 

Messungen mit Microsoft Terminal Services (RDP-Protokoll) 

Bis zu 40 Benutzer pro Lastgenerator 

Desktop + Applikationen: 

Notepad: Textdatei, 8.4 KB 

Microsoft Word: Word Dokument, 3.1 MB 

Acrobat Reader 7: PDF-Datei, 3.8 MB 

Abgesehen von der Benutzeranmeldung finden während des Tests keine Eingaben statt, 

es werden keine Daten durch die Anwendungen angelegt 

Messung der Logon-Zeiten sowie der Anzahl der gestarteten Verbindungen und 

Applikationen 


Eigenentwicklung von LoginConsultants (http://www.loginconsultants.com) 

VSI: kostenlose Version mit einem (Medium) Lastprofil, nicht anpassbar 

VSIpro: Lizenzpflichtige customize-fähige Version, verschiedene Lastprofile 

Messungen erfolgen auf dem SUT, daher Protokoll-unabhängig 

Medium Lastprofil: Login, Outlook, Internet Explorer, Word, Excel, PowerPoint, 

PDFWriter Aktionen 

Kontinuierliches Starten von Benutzer-Sessions und Messen von Reaktionszeiten 

Ergebnis VSI: die maximale Anzahl Virtual Sessions anhand der Reaktionszeiten 



Literatur 

[L1] 

[L2] 

[L3] 

[L4] 

[L5] 

[L6] 

[L7] 

[L8] 

[L9] 

[L10] 

[L11] 

Allgemeine Informationen zu Produkten von Fujitsu Technology Solutions 

http://de.ts.fujitsu.com 

Allgemeine Informationen zur PRIMERGY Produktfamilie 

http://www.primergy.de 

PRIMERGY Benchmarks - Performance Reports und Sizing Guides 

http://de.ts.fujitsu.com/products/standard_servers/primergy_bov.html 

Speicher-Performance Xeon 5500 (Nehalem EP) basierter PRIMERGY Server 

http://docs.ts.fujitsu.com/dl.aspx?id=3ba9fc71-4b0d-493f-b842-02a1d3645be0 

Performance Report - Modular RAID für PRIMERGY 

http://docs.ts.fujitsu.com/dl.aspx?id=2d0d20d8-7c14-407c-b904-6112f4c7821c 

Microsoft Windows 2003 und Terminal Server 

http://www.microsoft.com/terminalserver 

Windows Server 2003 Terminal Server Capacity and Scaling 

http://www.microsoft.com/windowsserver2003/techinfo/overview/tsscaling.mspx 

Remote Desktop Services Windows Server 2008 R2 

http://www.microsoft.com/windowsserver2008/en/us/rds-product-home.aspx 

Citrix 

http://www.citrix.de 

Sysinternals Tools 

www.sysinternals.com 

Microsoft Windows Performance Toolkit 

http://msdn.microsoft.com/en-us/performance/cc752957.aspx 

Kontakt 

PRIMERGY Hardware 

PRIMERGY Product Marketing 

mailto:Primergy-PM@ts.fujitsu.com 

PRIMERGY Performance und Benchmarks 

PRIMERGY Performance und Benchmarks 

mailto:primergy.benchmark@ts.fujitsu.com 

Lieferung vorbehaltlich Verfügbarkeit, technische Änderungen ohne 

Vorankündigung möglich, Korrektur von Irrtümern und Auslassungen 

vorbehalten. 

Alle angegebenen Konditionen (TCs) sind empfohlene Einstandspreise in 

Euro ohne MwSt. (sofern im Text nicht anderweitig angegeben). Sämtliche 

verwendete Hardware- und Software- Namen sind Handelsnamen und/oder 

Warenzeichen ihrer jeweiligen Hersteller. 

Copyright © Fujitsu Technology Solutions GmbH 2009 

Herausgegeben durch: 

Enterprise Products 

PRIMERGY Server 

PRIMERGY Performance Lab 

mailto:primergy.benchmark@ts.fujitsu.com 

Internet: 

http://ts.fujitsu.com/primergy 

Extranet: 

http://partners.ts.fujitsu.com/com/products/serv 

ers/primergy

Terminal Server Sizing Guide - Fujitsu

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?