Siemens RX100 S4 User Manual

Version 2.2

Performance Report PRIMERGY RX100 S4

Seiten 27

Juni 2007

Abstract

In diesem Dokument sind alle Benchmarks, die für die PRIMERGY RX100 S4 durchgeführt wurden, zusammengefasst. Ferner werden die Leistungsdaten der PRIMERGY RX100 S4 mit denen anderer PRIMERGY Modelle verglichen und

diskutiert. Neben den Benchmark-Ergebnissen als solchen wird jeder Benchmark und die Umgebung, in der der Benchmark durchgeführt wurde, kurz erläutert.

Inhalt

Technische Daten ...................................................................................................................................................2

SPECcpu2000.........................................................................................................................................................3

SPECcpu2006.........................................................................................................................................................7

SPECjbb2005........................................................................................................................................................10

StorageBench .......................................................................................................................................................12

Terminal Server.....................................................................................................................................................21

Literatur.................................................................................................................................................................27

Kontakt..................................................................................................................................................................27

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Technische Daten

Die PRIMERGY RX100 S4 ist wie ihr Vorgänger PRIMERGY RX100 S3 ein Mono-Prozessor Rack Server von einer Höheneinheit. Sie enthält den Intel 3000 Chipsatz, einen Intel Celeron D, Pentium D oder Xeon Prozessor, bis zu 8 GB ECC-geschützten DDR2-533 SDRAM, je nach eingesetztem Prozessor einen mit 533 (Celeron D), 800 (Pentium D) oder 1067 MHz (Xeon) getakteten Front-Side-Bus, einen Broadcom BDC5715 2-Kanal 1-GBit Ethernet-Controller und Platz für 2 Festplatten. Die SAS-Variante der PRIMERGY RX100 S4 besitzt einen 8-Port SAS-Controller, die SATA-Variante einen 2-Port SATA 300 Controller, beide mit RAID-0 und RAID-1 Funktionalität.

Detaillierte technische Informationen finden Sie unter

http://www.fujitsu-siemens.de/products/standard_servers/rack/primergy_rx100s4.html.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

SPECcpu2000

∗

Benchmark-Beschreibung

SPECcpu2000 ist ein Benchmark, der die Systemeffizienz bei Integer- und Fließkomma-Operationen misst. Er besteht aus einer Integer-Testsuite (SPECint2000), die 12 Applikationen enthält, und einer Fließkomma-Testsuite (SPECfp2000), die 14 Applikationen enthält. Beide Testsuiten sind extrem rechenintensiv und konzentrieren sich auf die CPU und den Speicher. Andere Komponenten, wie Disk-I/O und Netzwerk, werden von diesem Benchmark nicht vermessen.

SPECcpu2000 ist nicht an ein spezielles Betriebssystem gebunden. Der Benchmark ist als Source-Code verfügbar und wird vor der eigentlichen Messung kompiliert. Daher gehen die verwendete Compiler-Version und -Optimierungseinstellungen in die Messung mit ein.

SPECcpu2000 beinhaltet zwei verschiedene Methoden der Performance-Messung: Die erste Methode (SPECint2000 bzw. SPECfp2000) ermittelt die Zeit, die für die Bearbeitung einer bestimmten Aufgabe benötigt wird. Die zweite Methode (SPECint_rate2000 bzw. SPECfp_rate2000) ermittelt den Durchsatz, d.h. wie oft eine Aufgabe in einer vorgegebenen Zeit erledigt werden kann. Beide Methoden werden zusätzlich noch in zwei Messläufe unterteilt, „base“ und „peak“, die sich in der Verwendung der Compiler-Optimierung unterscheiden. Bei der Publikation von Ergebnissen werden immer „base“-Werte verwendet, „peak“-Werte sind optional.

Benchmark Arithmetik Typ

SPECint2000 Integer peak aggressiv SPECint_base2000 Integer base konservativ SPECint_rate2000 Integer peak aggressiv SPECint_rate_base2000 Integer base konservativ SPECfp2000 Fließkomma peak aggressiv SPECfp_base2000 Fließkomma base konservativ SPECfp_rate2000 Fließkomma peak aggressiv SPECfp_rate_base2000 Fließkomma base konservativ

Bei den Messergebnissen handelt es sich um das geometrische Mittel aus normalisierten Verhältniswerten, die für die Einzel-Benchmarks ermittelt wurden. Normalisiert heißt, dass gemessen wird, wie schnell das Testsystem verglichen mit einem Referenzsystem ist. Für das Referenzsystem wurde als SPECint_2000- und SPECfp_2000-Wert 100 festgelegt. Im Falle der rate-Messergebnisse liegt dieser Wert bei 1.16. So bedeutet beispielsweise ein SPECint_base2000-Wert von 200 für das Messsystem, dass es diesen Benchmark mindestens doppelt so schnell wie das Referenzsystem bewältigt hat. Die ungenaue Bezeichnung „mindestens“ deshalb, weil bei der Berechnung des Ergebnisses das geometrische Mittel angewandt wird. Gegenüber dem arithmetischen Mittel führt dies dazu, dass bei unterschiedlich hohen Einzelergebnissen eine Gewichtung zugunsten der niedrigeren Einzelergebnisse erfolgt.

Die SPECcpu2000-Messungen werden von uns in der Regel nur für ausgewählte Systeme und Systemkonfigurationen zur Veröffentlichung bei SPEC eingereicht. Daher erscheinen die meisten der hier vorgestellten Ergebnisse auch nicht auf den Web-Seiten von SPEC. Da wir für alle Messungen die Protokolldateien archivieren, können wir jederzeit den Nachweis für die korrekte Durchführung der Messungen erbringen. Die so ermittelten Ergebnisse dürfen daher veröffentlicht werden.

CompilerOptimierung

Messergebnis Anwendung

Geschwindigkeit Monoprozessor

Durchsatz

Geschwindigkeit Monoprozessor

Durchsatz

Mono- und Multiprozessor

Benchmark-Ergebnisse

Es wurden Messungen mit dem Celeron D Prozessor 352, den Pentium D Prozessoren 925 und 945 sowie den Xeon Prozessoren 3040, 3050, 3060 und 3070 durchgeführt. Die SPECint-Benchmark-Programme wurden als 32-BitVersionen mit dem Intel C++/Fortran-Compiler 9.1 kompiliert und unter Windows Server 2003 Enterprise Edition SP1 (32-bit) ausgeführt. Die SPECfp-Benchmark-Programme wurden als 64-Bit-Versionen mit dem Intel C++/FortranCompiler 9.0 kompiliert und unter SUSE Linux Enterprise Server 10 (64-bit) ausgeführt.

∗

SPEC®, SPECint®, SPECfp® und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance

Evaluation Corporation (SPEC).

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Prozessor Cores/Chip GHz SLC FSB SPECint_base2000 SPECint_rate_base2000

Celeron D 352 1 3.20 ½ MB 533 MHz 1281 Pentium D 925 2 3 2 MB pro Core 800 MHz n/a 34.6 Pentium D 945 2 3.40 2 MB pro Core 800 MHz 1723

14.9

38.7

Xeon 3040 2 1.87 2 MB pro Chip 1067 MHz n/a 39.8 Xeon 3050 2 2.13 2 MB pro Chip 1067 MHz n/a 43.9 Xeon 3060 2 2.40 4 MB pro Chip 1067 MHz 2593 Xeon 3070 2 2.67 4 MB pro Chip 1067 MHz n/a 58.8

53.8

*) nicht veröffentlicht bei

http://www.spec.org

Prozessor Cores/Chip GHz SLC FSB SPECfp_base2000 SPECfp_rate_base2000

Celeron D 352 1 3.20 ½ MB 533 MHz 1569 Pentium D 925 2 3 2 MB pro Core 800 MHz n/a 36.9 Pentium D 945 2 3.40 2 MB pro Core 800 MHz 2135

18.2

39.2

Xeon 3040 2 1.87 2 MB pro Chip 1067 MHz n/a 35.9 Xeon 3050 2 2.13 2 MB pro Chip 1067 MHz n/a 37.6 Xeon 3060 2 2.40 4 MB pro Chip 1067 MHz 2573 Xeon 3070 2 2.67 4 MB pro Chip 1067 MHz n/a 46.4

44.7

*) nicht veröffentlicht bei

http://www.spec.org

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Leistungszuwächse, die sich allein aus einer höheren Prozessortaktfrequenz generieren, fallen bei der Integer-Testsuite von SPECcpu2000 höher aus als bei der Floating-Point-Testsuite. Dies liegt daran, dass die Floating-Point-Testsuite mehr Speicher benötigt. Gegenüber Cache-Zugriffen wirken sich die langsameren RAM-Speicherzugriffe stärker auf das Messergebnis aus. Daher profitieren Prozessoren mit großen Caches, die den Speicher entlasten, stärker bei der Floating-Point-Testsuite als bei der Integer-Testsuite.

Der Pentium D 925 und der Pentium D 945 unterscheiden sich lediglich bezüglich der Prozessortaktrate. Die im Vergleich zum Pentium D 925 höhere Taktrate des Pentium D 945 wurde in der Integer-Testsuite zu 89% und in der speicherintensiveren Floating-Point-Testsuite zu 47% in zusätzliche Performance umgesetzt. Die Xeon Prozessoren verfügen gegenüber den Pentium D Prozessoren zwar über eine geringere Prozessortaktrate, dafür aber über eine höhere Taktung des Front-Side-Busses. Unterschiedlich ist bei den beiden Prozessortypen auch die Cache-Organisation. Auch der Xeon 3040 und der Xeon 3050 sowie der Xeon 3060 und der Xeon 3070 unterscheiden sich nur bezüglich der Prozessortaktrate. Xeon 3060 und 3070 besitzen gegenüber den Xeon 3040 und 3050 einen doppelt so großen Second Level Cache, der hauptverantwortlich für deren deutlich bessere Performance ist. Die im Vergleich zum Xeon 3060 höhere Taktrate des Xeon 3070 wurde in der Integer-Testsuite zu 84% und in der speicherintensiveren Floating-Point-Testsuite zu 34% in zusätzliche Performance umgesetzt.

Die beiden folgenden Grafiken zeigen Ergebnisse der PRIMERGY RX100 S4 im Vergleich zu ihren Vorgängern in der jeweils performantesten Ausstattung. Gegenüber der PRIMERGY RX100 S3 wurde die Integer-Performance um 55% und die Floating-Point-Performance um 19% verbessert. Zu beachten ist, dass die Ergebnisse der PRIMERGY RX100 S4 auf Benchmark-Programmen basieren, die mit einer neueren Compiler-Version erstellt wurden. Daher ist das gute Abschneiden der PRIMERGY RX100 S4 im Vergleich zur ihren Vorgängern nicht ausschließlich systembedingt, sondern teilweise auch auf die neuere Compiler-Version zurückzuführen.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Benchmark-Umgebung

Alle SPECcpu2000 Messungen wurden auf einer PRIMERGY RX100 S4 mit folgender Hard- und Software-Ausstattung vorgenommen:

Hardware

Model PRIMERGY RX100 S4

Celeron D 352

CPU

Anzahl CPUs 1

Primary Cache

Secondary Cache

Memory 8 GB DDR2-533 SDRAM

Software

Betriebssystem

Compiler

Pentium D 925 und 945 Xeon 3040, 3050, 3060 und 3070

Celeron D: 12 kB instruction + 16 kB data on chip Pentium D: 12 kB instruction + 16 kB data on chip, pro Core Xeon: 32 kB instruction + 32 kB data on chip, pro Core Celeron D: ½ MB (I+D) on chip Pentium D: 2 MB (I+D) on chip, pro Core Xeon 3040 und 3050: 2 MB (I+D) on chip, pro Chip Xeon 3060 und 3070: 4 MB (I+D) on chip, pro Chip

SPECint: Windows Server 2003 Enterprise Edition SP1 (32-bit) SPECfp: SUSE Linux Enterprise Server 10 (64-bit) SPECint: Intel C++/Fortran Compiler 9.1 SPECfp: Intel C++/Fortran Compiler 9.0

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

SPECcpu2006

∗

Benchmark-Beschreibung

SPECcpu2006 ist ein Benchmark, der die Systemeffizienz bei Integer- und Fließkomma-Operationen misst. Er besteht aus einer Integer-Testsuite (SPECint2006), die 12 Applikationen enthält, und einer Fließkomma-Testsuite (SPECfp2006), die 17 Applikationen enthält. Beide Testsuiten sind extrem rechenintensiv und konzentrieren sich auf die CPU und den Speicher. Andere Komponenten, wie Disk-I/O und Netzwerk, werden von diesem Benchmark nicht vermessen.

SPECcpu2006 ist nicht an ein spezielles Betriebssystem gebunden. Der Benchmark ist als Source-Code verfügbar und wird vor der eigentlichen Messung kompiliert. Daher beeinflussen auch die verwendete Compiler-Version und deren Optimierungseinstellungen das Messergebnis.

SPECcpu2006 beinhaltet zwei verschiedene Methoden der Performance-Messung: Die erste Methode (SPECint2006 bzw. SPECfp2006) ermittelt die Zeit, die für die Bearbeitung einer einzelnen Aufgabe benötigt wird. Die zweite Methode (SPECint_rate2006 bzw. SPECfp_rate2006) ermittelt den Durchsatz, d.h. wie viele Aufgaben parallel erledigt werden können. Beide Methoden werden zusätzlich noch in zwei Messläufe unterteilt, „base“ und „peak“, die sich in der Verwendung der Compiler-Optimierung unterscheiden. Bei der Publikation von Ergebnissen werden immer „base“-Werte verwendet, „peak“-Werte sind optional.

Benchmark Arithmetik Typ

SPECint2006 Integer peak aggressiv SPECint_base2006 Integer base konservativ SPECint_rate2006 Integer peak aggressiv SPECint_rate_base2006 Integer base konservativ SPECfp2006 Fließkomma peak aggressiv SPECfp_base2006 Fließkomma base konservativ SPECfp_rate2006 Fließkomma peak aggressiv SPECfp_rate_base2006 Fließkomma base konservativ

Bei den Messergebnissen handelt es sich um das geometrische Mittel aus normalisierten Verhältniswerten, die für die Einzel-Benchmarks ermittelt wurden. Das geometrische Mittel führt gegenüber dem arithmetischen Mittel dazu, dass bei unterschiedlich hohen Einzelergebnissen eine Gewichtung zugunsten der niedrigeren Einzelergebnisse erfolgt. Normalisiert heißt, dass gemessen wird, wie schnell das Testsystem verglichen mit einem Referenzsystem ist. Der Wert „1“ wurde für die SPECint_base2006-, SPECint_rate_base2006, SPECfp_base2006 und SPECfp_rate_base2006Ergebnisse des Referenzsystems festgelegt. So bedeutet beispielsweise ein SPECint_base2006-Wert von 2, dass das Messsystem diesen Benchmark etwa doppelt so schnell wie das Referenzsystem bewältigt hat. Ein SPECfp_rate_base2006-Wert von 4 bedeutet, dass das Messsystem diesen Benchmark etwa 4/[# base copies] mal so schnell wie das Referenzsystem bewältigt hat. „# base copies“ gibt hierbei an, wie viele parallele Instanzen des Benchmarks ausgeführt worden sind.

Nicht alle SPECcpu2006-Messungen werden von uns zur Veröffentlichung bei SPEC eingereicht. Daher erscheinen auch nicht alle Ergebnisse auf den Web-Seiten von SPEC. Da wir für alle Messungen die Protokolldateien archivieren, können wir jederzeit den Nachweis für die korrekte Durchführung der Messungen erbringen.

CompilerOptimierung

Messergebnis Anwendung

Geschwindigkeit Singlethreaded

Durchsatz Multithreaded

Geschwindigkeit Singlethreaded

Durchsatz Multithreaded

Benchmark-Ergebnisse

Es wurden Messungen mit den Prozessoren Pentium D 925 und 945 sowie den Prozessoren Xeon 3040, 3050, 3060 und 3070 durchgeführt. Alle Benchmark-Programme wurden mit dem Intel C++/Fortran-Compiler 9.1 kompiliert und unter SUSE Linux Enterprise Server 10 (64-bit) ausgeführt.

∗

SPEC®, SPECint®, SPECfp® und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance

Evaluation Corporation (SPEC).

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Prozessor Cores/Chip GHz SLC FSB SPECint_rate_base2006 SPECint_rate2006

Celeron D 352 1 3.20 ½ MB 533 MHz n/a n/a Pentium D 925 2 3 2 MB pro Core 800 MHz 18.7 19.5 Pentium D 945 2 3.40 2 MB pro Core 800 MHz 20.6 21.4 Xeon 3040 2 1.87 2 MB pro Chip 1067 MHz Xeon 3050 2 2.13 2 MB pro Chip 1067 MHz Xeon 3060 2 2.40 4 MB pro Chip 1067 MHz Xeon 3070 2 2.67 4 MB pro Chip 1067 MHz

21.6 22.6

23.4 24.5

27.3 28.7

29.3 30.8

Fett gedruckte Ergebnisse sind veröffentlicht bei

http://www.spec.org.

Die gemessenen SPECint_rate_2006-Ergebnisse liegen durchgängig 4-5% über den SPECint_rate_base2006Ergebnissen.

Prozessor Cores/Chip GHz SLC FSB SPECfp_rate_base2006 SPECfp_rate2006

Celeron D 352 1 3.20 ½ MB 533 MHz n/a n/a Pentium D 925 2 3 2 MB pro Core 800 MHz 18.4 18.9 Pentium D 945 2 3.40 2 MB pro Core 800 MHz 19.8 20.4 Xeon 3040 2 1.87 2 MB pro Chip 1067 MHz Xeon 3050 2 2.13 2 MB pro Chip 1067 MHz Xeon 3060 2 2.40 4 MB pro Chip 1067 MHz Xeon 3070 2 2.67 4 MB pro Chip 1067 MHz

19.8 20.4

21.1 21.8

23.7 24.3

25.0 25.9

Fett gedruckte Ergebnisse sind veröffentlicht bei

http://www.spec.org.

Die gemessenen SPECfp_rate_2006-Ergebnisse liegen durchgängig 3-4% über den SPECfp_rate_base2006-Ergebnissen.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Der Pentium D 925 und der Pentium D 945 unterscheiden sich lediglich bezüglich der Prozessortaktrate. Die im Vergleich zum Pentium D 925 höhere Taktrate des Pentium D 945 wurde in der Integer-Testsuite zu 76% (base) bzw. 73% (peak) und in der Floating-Point-Testsuite zu 57% (base) bzw. 60% (peak) in zusätzliche Performance umgesetzt. Die Xeon Prozessoren verfügen gegenüber den Pentium D Prozessoren zwar über eine geringere Prozessortaktrate, dafür aber über eine höhere Taktung des Front-Side-Busses. Unterschiedlich ist bei den beiden Prozessortypen auch die Cache-Organisation. Auch der Xeon 3040 und der Xeon 3050 sowie der Xeon 3060 und der Xeon 3070 unterscheiden sich nur bezüglich der Prozessortaktrate. Xeon 3060 und 3070 besitzen gegenüber den Xeon 3040 und 3050 einen doppelt so großen Second Level Cache, der hauptverantwortlich für deren deutlich bessere Performance ist. Die im Vergleich zum Xeon 3060 höhere Taktrate des Xeon 3070 wurde in der Integer-Testsuite zu 66% (base und peak) und in der Floating-Point-Testsuite zu 49% (base) bzw. 59% (peak) in zusätzliche Performance umgesetzt.

Benchmark-Umgebung

Alle SPECcpu2000 Messungen wurden auf einer PRIMERGY RX100 S4 mit folgender Hard- und Software-Ausstattung vorgenommen:

Hardware

Model PRIMERGY RX100 S4

CPU

Anzahl CPUs 1

Primary Cache

Secondary Cache

Memory 8 GB PC2-4200 DDR2-SDRAM

Software

Betriebssystem SUSE Linux Enterprise Server 10 (64-bit) Compiler Intel C++/Fortran Compiler 9.1

Pentium D 925 und 945 Xeon 3040, 3050, 3060 und 3070

Pentium D 945: 12 kB instruction + 16 kB data on chip, pro Core Xeon: 32 kB instruction + 32 kB data on chip, pro Core Pentium D 945: 2 MB (I+D) on chip, pro Core Xeon 3040 and 3050: 2 MB (I+D) on chip, pro Chip Xeon 3060 and 3070: 4 MB (I+D) on chip, pro Chip

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

SPECjbb2005

∗

Benchmark-Beschreibung

SPECjbb2005 ist ein Java Business Benchmark, dessen Fokus auf der Leistung von Java Server Plattformen liegt. Im Wesentlichen ist SPECjbb2005 ein modernisierter SPECjbb2000. Die Hauptunterschiede sind:

• Die Transaktionen sind komplexer geworden, um einen größeren Bereich an Funktionalität abzudecken.

• Der Working Set des Benchmarks ist vergrößert worden, so dass die Systemlast insgesamt gestiegen ist.

• SPECjbb2000 erlaubt nur eine aktive Java Virtual Machine Instanz (JVM), während SPECjbb2005 mehrere Instan-

zen zulässt, was eine größere Realitätsnähe insbesondere bei großen Systemen bewirkt.

Softwareseitig misst SPECjbb2005 die Effizienz der Implementierungen der JVM, Just-In-Time (JIT) Compilers, Garbage Collection, Threads sowie einige Aspekte des Betriebssystems. Hardwareseitig wird die Effizienz der CPUs und Caches, des Speichersubsystems und die Skalierbarkeit von Shared Memory Systemen (SMP) gemessen. Disk- und NetzwerkI/O spielen keine Rolle.

SPECjbb2005 emuliert ein für moderne Geschäftsprozess-Applikationen typisches Three-Tier Client/Server System mit Augenmerk auf das Middle-Tier System:

• Clients erzeugen die Last, bestehend aus Driver Threads, die angelehnt an den TPC-C Benchmark OLTP Zugriffe

auf eine Datenbank ohne Denkzeiten generieren.

• Das Middle-Tier System implementiert die Geschäftsprozesse und Aktualisierung der Datenbank.

• Die Datenbank übernimmt die Datenverwaltung und wird emuliert durch Java-Objekte, die im Memory liegen.

Transaktions-Logging ist implementiert auf XML Basis.

Der große Vorteil dieses Benchmarks ist, dass er alle drei Tiers beinhaltet, die gemeinsam auf einem Single-Host laufen. Gemessen wird die Performance des Middle-Tier. So werden große Hardware-Installationen vermieden und direkte Vergleiche von SPECjbb2005-Ergebnissen unterschiedlicher Systeme sind möglich. Client- und Datenbank-Emulation sind ebenfalls in Java geschrieben.

SPECjbb2005 benötigt nur das Betriebssystem sowie eine Java Virtual Machine mit J2SE 5.0 Eigenschaften. Die Skalierungseinheit ist ein Warenhaus mit ca. 25 MB Java Objekten. Genau ein Java-Thread pro Warenhaus führt die

Operationen auf diesen Objekten aus. Die Geschäftsoperationen sind von TPC-C übernommen:

• New Order Entry

• Payment

• Order Status Inquiry

• Delivery

• Stock Level Supervision

• Customer Report

Das sind aber auch die einzigen Gemeinsamkeiten von SPECjbb2005 und TPC-C. Die Ergebnisse beider Benchmarks sind nicht vergleichbar.

SPECjbb2005 besitzt 2 Performance-Metriken:

• bops (business operations per second) ist die Gesamtrate aller Geschäftsoperationen, die pro Sekunde durchge-

führt werden.

• bops/JVM ist der Quotient der ersten Metrik und der Anzahl der aktiven JVM Instanzen.

In Vergleichen verschiedener SPECjbb2005-Ergebnisse müssen beide Metriken angegeben werden. Grundlage für diese Metriken sind die folgenden Regeln, nach denen ein konformer Benchmark-Lauf durchgeführt

werden muss: Ein konformer Benchmarklauf besteht aus einer Sequenz von Messpunkten mit wachsender Anzahl von Warenhäusern

(und damit von Threads), wobei die Anzahl jeweils um ein Warenhaus erhöht wird. Gestartet wird mit einem Warenhaus bis zu 2*MaxWH, mindestens aber 8 Warenhäusern. MaxWh ist die Anzahl Warenhäuser, bei der der Benchmark die höchste Operationsrate pro Sekunde erwartet. Standardmäßig setzt der Benchmark MaxWH mit der Anzahl vom Betriebssystem erkannter CPUs gleich. Die Metrik bops ist das arithmetische Mittel aller gemessenen Operations-Raten mit MaxWh Warenhäusern bis 2*MaxWh Warenhäusern.

∗

SPEC®, SPECjbb® und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation

Corporation (SPEC).

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Benchmark-Ergebnisse

Im September 2006 wurde die PRIMERGY RX100 S4 mit einem Xeon 3060 Prozessor bei einem Speicherausbau mit 8 GB PC2-4200 DDR2-SDRAM vermessen. Die Messung wurde unter Windows Server 2003 Enterprise x64 Edition SP1 durchgeführt. Als JVM wurde eine Instanz von JRockit(R) 5.0 P26.4.0 (build P26.4.0-10-62459-1.5.0_06-200605292101-win-x86_64) von BEA verwendet.

Im Mai 2007 wurde die PRIMERGY RX100 S4 mit einem Xeon 3070 Prozessor vermessen. Als JVM wurde eine Instanz von JRockit(R) 5.0 P27.2.0 (build P27.2.0-19-82330-1.5.0_10-20070515-1627-windows-x86_64) von BEA verwendet. Alle weiteren Einstellungen blieben im Vergleich zur Messung von September 2006 unverändert.

Bei beiden Messungen flossen alle Ergebnisse von 2 bis 4 Warenhäusern in das Benchmark-Ergebnis ein.

Benchmark-Umgebung

Die SPECjbb2005 Messungen wurden auf einer PRIMERGY RX100 S4 mit folgender Hard- und Software-Ausstattung vorgenommen:

Hardware

Modell PRIMERGY RX100 S4 CPU Xeon 3060 und 3070 Anzahl Chips 1 Chip, 2 Kerne, 2 Kerne pro Chip Primary Cache 32 kB instruction + 32 kB data on chip, pro Kern Secondary Cache 4 MB (I+D) on chip, pro Chip Other Cache nein Memory 4 x 2 GB PC2-4200 DDR2-SDRAM

Software

Betriebssystem Windows Server 2003 Enterprise x64 Edition SP1

Xeon 3060: BEA JRockit(R) 5.0 P26.4.0 (build P26.4.0-10-62459-1.5.0_06-20060529-2101-

JVM Version

Xeon 3070: BEA JRockit(R) 5.0 P27.2.0 (build P27.2.0-19-82330-1.5.0_10-20070515-1627-

win-x86_64)

windows-x86_64)

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

StorageBench

Benchmark-Beschreibung

Um die Leistungsfähigkeit von Disk-Subsystemen zu beurteilen, wurde von Fujitsu Siemens Computers ein Benchmark mit dem Namen »StorageBench« definiert, mit dem ein Vergleich der verschiedenen Storage-Anbindungen möglich ist. StorageBench nutzt zu diesem Zweck das von der Firma Intel entwickelte Messwerkzeug Iometer mit einem definierten Satz von in der Praxis vorkommenden Lastprofilen und einem festgelegten Messszenario.

Messwerkzeug

Seit Ende 2001 ist Iometer ein Projekt bei http://SourceForge.net und wird von einer Gruppe internationaler Entwickler auf verschiedene Plattformen portiert und weiter entwickelt. Iometer besteht aus einer grafischen Bedieneroberfläche für Windows-Systeme und dem so genannten „dynamo“, der für verschiedene Plattformen verfügbar ist. Diese beiden Komponenten können seit einigen Jahren unter „Intel Open Source License“ von

http://sourceforge.net/projects/iometer herunter geladen werden.

Mit Iometer hat man die Möglichkeit, das Verhalten realer Anwendungen bezüglich der Zugriffe auf I/O-Subsysteme nachzubilden. Dazu kann man unter anderem die zu verwendenden Blockgrößen, die Art des Zugriffs wie sequentielles Lesen oder Schreiben, wahlfreies Lesen oder Schreiben und auch Mischungen davon konfigurieren. Als Ergebnis liefert Iometer eine Textdatei mit durch Komma separierten Werten (.csv) mit wesentlichen Kenngrößen wie z.B. Durchsatz pro Sekunde, Transaktionen pro Sekunde und durchschnittliche Antwortzeit für das jeweilige Zugriffsmuster. Auf diese Weise kann man die Leistungsfähigkeit verschiedener Subsysteme bei bestimmten Zugriffsmustern vergleichen. Iometer ist in der Lage, sowohl auf Subsysteme mit einem Dateisystem als auch auf so genannte Raw-Devices zuzugreifen.

Mit Iometer können die Zugriffsmuster verschiedenster Anwendungen simuliert und vermessen werden, jedoch bleibt der File-Cache des Betriebssystems außer acht und es wird blockmäßig auf einer einzelnen Testdatei operiert. Zur Untersuchung der Einflüsse des File-Caches und des Dateisystems ist es daher sinnvoll, ein weiteres Testwerkzeug einzusetzen, das Betriebssystemfunktionen und den File-Cache des Betriebssystems verwendet.

http://www.iometer.org oder

Lastprofil

Von erheblichem Einfluss auf die Performance eines Speichersystems ist die Art, wie Anwendungen auf den Massenspeicher zugreifen.

Beispiele für verschiedene Zugriffsmuster einiger Anwendungen:

Anwendung Zugriffsmuster

Datenbank (Datentransfer) random, 67% read, 33% write, 8 kB (SQL Server) Datenbank (Log File) sequential, 100% write, 64 kB Blöcke Backup sequential, 100% read, 64 kB Blöcke Restore sequential, 100% write, 64 kB Blöcke Video Streaming sequential, 100% read, 128 kB Blöcke File Server random, 70% read, 30% write (Blöcke ≥ 8 kB) Web-Server random, 100% read, 64 kB Blöcke Betriebssystem random, 40% read, 60% write (Blöcke ≥ 4 kB) File copy random, 50% read, 50% write, 64 kB Blöcke

Daraus kann man fünf markante Profile ableiten:

Zugriffsmuster Lastprofile Zugriff

read write Streaming sequential 100% 64 kB Iometer Restore sequential 100% 64 kB Iometer Database random 67% 33% 8 kB Iometer File Server random 67% 33% 64 kB Iometer File copy random 50% 50% 64 kB Copy

Block-

größe

Last-Tool

Die ersten vier Profile werden mit Iometer generiert. Bei dem Lastprofil "File copy" werden mit Betriebssystemfunktionen 500 MB Daten mit 712 Dateien in 64 Verzeichnissen kopiert und der Datendurchsatz ermittelt.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Messszenario

Um vergleichbare Messergebnisse zu erhalten ist es wichtig, alle Messungen in identischen reproduzierbaren Umgebungen durchzuführen. Daher liegen StorageBench neben dem oben beschriebenen Lastprofil die folgenden Regeln zugrunde:

• Da in realen Kundenkonfigurationen nur in Ausnahmefällen mit Raw-Devices gearbeitet wird, sind bei den

Untersuchungen zur Leistungsfähigkeit der internen Festplatten diese immer mit einem Dateisystem formatiert. Für Windows wird NTFS, für Linux ext3 verwendet, auch wenn mit anderen Dateisystemen oder Raw-Devices eventuell eine höhere Leistung erreicht werden könnte.

• Festplatten gehören zu den fehleranfälligsten Komponenten eines Computersystems. Daher werden in

Serversystemen RAID-Controller eingesetzt, um dem Datenverlust durch den Ausfall von Festplatten vorzubeugen. Dabei werden mehrere Festplatten zu einem »Redundant Array of Independent Disks«, kurz RAID, zusammengefasst. Dabei werden die Daten über mehrere Festplatten derart verteilt, dass auch beim Ausfall einer Festplatte alle Daten erhalten bleiben. Die gebräuchlichsten Arten um Festplatten in Verbänden zu organisieren sind die RAID-Level RAID-1, RAID-5 und RAID-10. Informationen zu den Grundlagen verschiedener RAID-Verbände sind im Papier

Disk Subsystem Sizing – RAID Controller zu finden.

Für die StorageBench Untersuchungen der PRIMERGY Server werden die je nach Plattenanzahl und eingebautem Controller möglichen RAID-Konfigurationen verwendet. Bei Systemen mit zwei Festplatten RAID-1, bei drei und mehr Festplatten zusätzlich RAID-5 und bei vier und mehr Festplatten zusätzlich RAID-10 – sofern der Controller diese RAID-Level unterstützt.

• Für die Messung wird immer eine Messdatei mit einer Größe von 8 GB verwendet, unabhängig von der Größe

der Festplatte.

• Bei der Beurteilung der Leistungsfähigkeit von I/O-Subsystemen spielen bei heutigen Systemen die

Prozessorleistung und der Speicherausbau des Systems keine signifikante Rolle – ein eventuell vorhandener Engpass betrifft in der Regel die Festplatten und den RAID-Controller und nicht CPU und Memory. Daher brauchen unterschiedliche Ausbauvarianten mit CPU und Speicher unter StorageBench nicht untersucht zu werden.

Messergebnisse

StorageBench liefert pro Lastprofil verschiedene Kenngrößen: z.B. den »Datendurchsatz« in Megabytes pro Sekunde, kurz MB/s, die »Transaktionsrate« in I/O-Operationen pro Sekunde, kurz IO/s, und die »Latenzzeit« oder auch »mittlere Zugriffszeit« in ms. Für die sequentiellen Lastprofile ist der Datendurchsatz die signifikante Messgröße, während bei den random Lastprofilen mit ihren kleinen Blockgrößen weniger der Datendurchsatz als vielmehr die Transaktionsrate relevant ist.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Benchmark-Ergebnisse

Die PRIMERGY RX100 S4 kann mit maximal zwei 3½" Festplatten bestückt werden. Trotz dieses begrenzten Ausbaus steht eine Vielzahl von Konfigurationen zur Verfügung. So ist die PRIMERGY RX100 S4 in zwei Varianten verfügbar: eine Variante mit SATA-Controller onboard und eine SAS-Variante mit einem onboard SAS-Controller. Die SAS-Variante wiederum kann sowohl mit SAS- als auch mit SATA-Festplatten betrieben werden. Die Bandbreite der zur Verfügung stehenden Festplatten reicht hinsichtlich der Kapazität von 36 GB bis 500 GB und bezüglich der Umdrehungsgeschwindigkeit von 7.2 krpm bis 15 krpm (rpm = revolutions per minute).

PRIMERGY RX100 S4 SATA

Die SATA-Variante der PRIMERGY RX100 S4 nutzt den SATA-Controller des Chip-Satzes Intel ICH7-R. Die Laufwerkseinschübe der PRIMERGY RX100 S4 SATA stehen wahlweise als easy-change oder hot-plug zur Verfügung. Dies hat jedoch keine Auswirkung auf die Performance.

Der SATA-Controller kann in vier Modi betrieben werden:

Compatible Die SATA-Ports werden auf PATA-Ports (PATA = parallel ATA) abgebildet. Dieser Betriebsmodus

sollte nur dann verwendet werden, wenn das verwendete Betriebssystem keine SATA-Treiber für den ICH7-R bietet oder diese aus anderen Gründen nicht eingesetzt werden sollen.

Native In dieser Betriebsart werden die SATA-Ports als solche dem Betriebssystem sichtbar gemacht. Es

werden entsprechende SATA-Treiber benötigt, die auf der ServerStart DVD für die unterstützen Betriebssysteme mitgeliefert werden.

AHCI AHCI steht für Advanced Host Controller Interface und stellt einen erweiterten Betriebsmodus für

SATA-Festplatten dar. Auch hierfür sind spezielle Treiber im Betriebssystem notwendig. AHCI-Treiber ermöglichen es, die Funktionalitäten des SATA II-Standards, wie z.B. Native Command Queuing (NCQ) zu nutzen. Hierzu muss jedoch der Schreibcache der Festplatten zwingend eingeschaltet sein.

RAID Für die RAID-Funktionalität RAID-0 und RAID-1 ist ein Software-RAID LSI Logic Embedded

MegaRAID im BIOS integriert. Die Matrix-RAID-Funktionalität des Intel ICH7-R steht hierbei nicht zu Verfügung.

Zwischen den einzelnen Betriebsmodi sind durchaus Performance-Unterschiede zu verzeichnen. Die nebenstehende Grafik und Tabelle zeigt Messergebnisse jeweils mit einer Festplatte (JBOD) in den vier Betriebsmodi Compatible, Native, AHCI und RAID. Alle Messungen wurden mit einer 500 GB Festplatte WD5000KS mit eingeschaltetem Festplattencache durchgeführt. Während bei sequentiellem Zugriff die Unterschiede im Bereich der Messungenauigkeit liegen, so zeigen sich bei random Zugriffen Leistungsvorteile im Betriebsmodus AHCI. Dies ist auf Funktionalitäten wie Native Command Queuing (NCQ) zurückzuführen.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Einen weiteren signifikanten Einfluss auf die Disk-I/O-Performance hat der Cache der Festplatten. Dieser wird leider häufig als Sicherheitsproblem bei Stromausfall angesehen und daher abgeschaltet. Andererseits wurde er von den Festplattenherstellern aus gutem Grund zur Steigerung der Schreibperformance integriert. Features, wie Native Command Queuing (NCQ) funktionieren gar nur, wenn der Plattencache eingeschaltet ist. Aus Performance-Gründen ist es gerade bei den, im Vergleich zu SAS-Festplatten, langsam drehenden SATA-Festplatten empfehlenswert, den Platten-Cache einzuschalten. Der weitaus größere Cache für I/O-Zugriffe und damit potentielles Sicherheitsrisiko für Datenverluste bei Stromausfall sitzt ohnehin im Arbeitsspeicher und wird vom Betriebssystem verwaltet. Um Datenverlusten vorzubeugen, empfiehlt es sich, das System mit einer unterbrechungsfreien Stromversorgung (USV) auszustatten.

Die nebenstehende Abbildung zeigt den Einfluss des Caches der Festplatte. Um in der grafischen Darstellung die unterschiedlichen absoluten Datendurchsätze der einzelnen Lastprofile auszugleichen, wurde eine relative Darstellung gewählt. Dabei wurde der bei eingeschaltetem Cache erreichte Datendurchsatz auf eins normiert, und der Datendurchsatz ohne Cache als prozentualer Anteil dargestellt. Man erkennt, dass beim reinen sequentiellen Schreiben der Festplattencache zu einer Verzehnfachung der Leistung führt. Mit Cache hat die Festplatte beim sequentiellen Schreiben und Lesen bei einer Blockgröße von 64 kB etwa die gleiche Datentransferleistung von 70 MB/s. Ohne den Festplatten-Cache sinkt die Schreibleistung auf ein Zehntel ab. Nicht ganz so dramatisch sieht es bei random Zugriffen mit

/3 lesenden und nur 1/3 schreibenden Zugriffen aus. Hier wird ohne Cache immerhin noch ca. 80% der möglichen Leistung erreicht. Bei einem Filecopy ohne Festplatten-Cache werden hingegen nur knapp 20% der möglichen Leistung erreicht. (Alle Messungen wurden mit einer 500 GB Festplatte WD5000KS im Betriebsmodus Native durchgeführt.)

Obgleich alle SATA-Festplatten, die für die PRIMERGY RX100 S4 freigeben sind, identische Leistungsdaten von 7200 Umdrehungen pro Minute (rpm) und eine Zugriffszeit von kleiner 4 ms aufweisen, so gibt es doch Leistungsunterschiede im Detail. Bei fast allen Zugriffsmustern zeigen Festplatten mit größerer Kapazität einen höheren Datendurchsatz. Dies erklärt sich durch die höhere Datendichte, bzw. größere Anzahl an Schreib-/Lese-Köpfen, die bei Festplatten größerer Kapazität zum Einsatz kommen. Daher können mehr Daten während einer Umdrehung der Festplatte verarbeitet werden.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Einen weiteren Einfluss auf die Leistungsfähigkeit eines Disk-Subsystems hat der verwendete RAID-Level. Alle bislang vorgestellten Messergebnisse wurden zwecks Vergleichbarkeit mit nur einer Festplatte JBOD (Just a Bunch Of Disks) durchgeführt. Die PRIMERGY RX100 S4 fasst nur zwei Festplatten. Von daher kommen nur der RAID-Level 1 (Datenspiegelung) oder RAID-0 (Daten-Striping) in Betracht. Dabei ist zu beachten, dass RAID-0 zwar eine höhere Performance, aber keinerlei Datenredundanz beim Ausfall einer Festplatte bietet. Daher ist RAID-0 nur für Server sinnvoll, deren Daten jederzeit reproduziert werden können, zum Beispiel in read-only Web-Serverfarmen.

Neben der im BIOS integrierten RAID-Funktionalität kann auch die Software-RAID-Funktionalität des Betriebssystems genutzt werden. Dabei bietet Letzteres sogar flexiblere Lösungen, wie beispielsweise auf einem Teil der beiden Festplatten ein sicheres RAID-1 für Betriebssystem und wichtige Daten und auf dem anderen Teil ein schnelles unsicheres RAID-0 für Daten, auf die sehr schnell zugegriffen werden muss, einzurichten.

JBOD und RAID-1 (Datenspiegel) schneiden in der Performance nahezu gleich ab. Beim sequentiellen Schreiben ist RAID-1 2% bis 5% langsamer. Bei random Zugriffen mit lesendem und schreibenden Anteil ist das Software-RAID-1 des Betriebssystems (in diesem Test Windows 2003 R2) dem BIOS-RAID-1 mit einem 70% höheren Datendurchsatz deutlich überlegen. Ähnliches gilt auch für RAID-0: hier ist das Software-RAID mit einer bis zu 40% höheren Leistung beim Datenbankzugriffsmuster dem BIOS-RAID-0 überlegen.

Interessant ist auch hier wieder der Einfluss des Festplattencaches. Während er im Betriebsmodus AHCI ohnehin immer eingeschaltet ist, zeigt sich im RAID Betriebsmodus mit RAID-1 bei abgeschaltetem Cache ein deutlicher Einbruch der Schreibleistung um den Faktor 7 auf nur 14%, auch wenn dieser Einbruch nicht ganz so gravierend ist wie im Betriebsmodus Native mit JBOD (siehe oben). Bei random Zugriffen mit gemischtem Schreib- und Leseanteil fällt der Performance-Verlust nicht ganz so gravierend aus, sinkt aber immer noch auf 80% bis 30%, je nach Zugriffsmuster.

(Alle Messungen wurden mit einer 500 GB Festplatte WD5000KS im Betriebsmodus RAID, bzw. AHCI für SoftwareRAID durchgeführt.)

Fazit:

Bei SATA-Festplatten kann auf den Festplattencache nicht verzichtet werden, ohne dass ein gravierender PerformanceVerlust hingenommen werden muss. Für maximale Performance sollte der SATA-Betriebsmodus AHCI gewählt werden. Die Software-RAID-Lösung des Betriebssystems zeigt sich gegenüber dem BIOS-RAID performanter und hinsichtlich der Konfigurationsmöglichkeiten flexibler.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

PRIMERGY RX100 S4 SAS

Die SAS-Variante der PRIMERGY RX100 S4 beinhaltet onboard einen LSI Logic 1068 SAS RAID Controller. Wahlweise können SAS-Festplatten mit einer Umdrehungsgeschwindigkeit von 10 krpm oder 15 krpm, oder SATA-Festplatten mit

7.2 krpm verwendet werden.

Die Grafik zeigt die drei Leistungsklassen der verfügbaren Festplatten im Vergleich. Es wurde jeweils die Leistung einer einzelnen Festplatte (JBOD) vermessen. Aufgrund der unterschiedlichen Umdrehungsgeschwindigkeiten der Festplatten fällt das Ergebnis nicht überraschend aus.

Interessant ist, dass die SAS-Festplatten mit 10 krpm und 15 krpm beim sequentiellen Schreiben auch ohne Cache der Festplatte einen sehr guten Datendurchsatz haben. Auch bei random Zugriffen ist der Einfluss des Festplattencaches bei SAS-Festplatten nicht ganz so gravierend wie bei der SATA-Festplatte mit 7.2 krpm.

Vergleicht man die Festplatten jeweils bei eingeschaltetem Festplattencache, so ist die 10 krpm SAS-Festplatte gegenüber der SATA-Festplatte mit 7.2 krpm je nach Zugriffsmuster 23% bis 150% leistungsfähiger. Insbesondere bei random Zugriffen ist die SAS-Festplatte wesentlich schneller. Die 15 krpm Festplatte ist gegenüber der 10 krpm Festplatte ca. 40% performanter.

Die SATA-Festplatten mit 7.2 krpm zeigen in der PRIMERGY RX100 S4 SAS nahezu die gleiche Leistung wie in der PRIMERGY RX100 S4 SATA. Es ergeben sich nur leichte Unterschiede in Abhängigkeit von den bereits im vorangegangenen Kapitel diskutierten Betriebsmodi des SATA-Controllers. Es ist also wenig sinnvoll, eine PRIMERGY RX100 S4 SAS mit SATA-Festplatten zu bestücken, wenn die gleiche Performance auch mit der kostengünstigeren PRIMERGY RX100 S4 SATA erreicht werden kann.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Anders als bei den SATA-Festplatten zeigt sich bei den SAS-Festplatten keine große Leistungsabweichung in Abhängigkeit von der Festplattengröße. So zeigen die Festplatten einer Serie (Cheetah T10, Cheetah 15K.5) die gleiche Leistung unabhängig von der Kapazität. Es gibt jedoch Leistungsunterschiede zwischen den einzelnen Festplatten-Serien. So zeigt, wie in der Grafik zu sehen ist, die 36 GB-Festplatte der Serie Cheetah 15K.4 bei sequentiellen Zugriffen eine deutlich schlechtere Performance als die Festplatten der Serie Cheetah 15K.5 und sie ist sogar langsamer als die Festplatten

mit 10 krpm der Serie Cheetah T10. Bei random Zugriffen profitiert die Cheetah 15K.4 aber klar mit mehr als 30% besserer Performance von der höheren Rotationsgeschwindigkeit gegenüber den Festplatten mit 10 krpm. Die 15 krpm Festplatten der Serie Cheetah 15K.5 zeigen dieses Verhalten nicht und sind in allen Bereichen mehr als 30% performanter als die 10 krpm Festplatten der Serie Cheetah T10.

Diese obigen Messungen wurde jeweils mit einer einzelnen Festplatte (JBOD) durchgeführt, um die Leistungsfähigkeit einer einzelnen Festplatte vergleichen zu können. In der Praxis dürften mehr das sichere RAID-1 und, wenn es um ultimative Performance geht, RAID-0 interessant sein. Die folgende Grafik zeigt die erreichbaren Datendurchsätze von JBOD, RAID-1 und RAID-0 bei Festplatten mit 10 krpm der Cheetah T10 Serie.

Man erkennt bei random Zugriffen einen Performance-Vorteil von ca. 25% bei einem RAID-1 gegenüber einer einzelnen Festplatte (JBOD). Dies erklärt sich dadurch, dass beim Lesen auf beide Festplatten im Spiegel (RAID-1) zugegriffen werden kann. Bei sequentiellen Zugriffen wirkt sich dies nicht aus, so dass die Performance eines RAID-1 und JBOD identisch ist. Anders beim RAID-0, bei dem die Daten über zwei Festplatten verteilt werden (Striping): hier kann auch bei

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

sequentiellem Lesen von beiden Festplatten profitiert werden. Je nach Zugriffsmuster kann auch bei den RAID-Konfigurationen die Performance um bis 25% gesteigert werden, indem der Cache der Festplatte eingeschaltet wird.

Ein etwas anderes Bild ergibt sich für die Festplatten mit 15 krpm:

Im Vergleich zu Festplatten mit 10 krpm erreichen auch bei RAID-1 und RAID-0 die Festplatten mit 15 krpm einen ca. 30% höheren Datendurchsatz. Allerdings hat der Festplattencache einen wesentlich größeren Einfluss. Ohne Festplattencache bricht die Performance beim sequentiellen Schreiben gegenüber einer einzelnen Festplatte (JBOD) sogar um mehr als den Faktor zwei ein. Bei einem RAID-1 bringt der Festplattencache, je nach Zugriffsmuster, zwischen 18% und 44% mehr Leistung, bei einem RAID-0 zwischen 15% und 128%.

Betrachtet man die Datendurchsätze der einzelnen Zugriffsmuster, so drängt sich die Frage auf, warum die Datendurchsätze bei random Zugriffen, und im speziellen bei dem Datenbank-Profil, im Vergleich zu sequentiellen Zugriffen so extrem gering sind. Dies wird transparent, wenn man anstelle des Datendurchsatzes die Disk-I/O-Rate betrachtet. Datendurchsatz und Disk-I/O-Rate sind direkt proportional zueinander und lassen sich nach der Formel

-1

Datendurchsatz MB/s = Disk-I/Os

× Blockgröße MB

berechnen. Die folgende Grafik zeigt die Anzahl Disk-I/Os bei random Zugriffen mit Blockgrößen von 1 kB bis 128 kB für die Festplatten der Klasse SATA 7.2 krpm, SAS 10 krpm und 15 krpm bei jeweils ein- und ausgeschaltetem Festplattencache.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Man erkennt deutlich, dass die Festplatten nur eine bestimmte Anzahl I/Os pro Sekunde bewältigen können. Mit steigender Blockgröße sinkt diese I/O-Rate sogar etwas ab. Die I/O-Rate hängt im wesentlichen von der Umdrehungsgeschwindigkeit der Festplatte, aber auch, da es sich hier um random Zugriffe handelt, von den Positionierungszeiten der Plattenköpfe und natürlich auch von der Datendichte, mit der die Daten gespeichert werden, ab. Bei einer Blockgröße von 64 kB ergibt sich für SATA-Platten mit 7.2 krpm eine typische I/O-Transferrate von 75, für SAS-Festplatten mit 10 krpm von 200 und für SAS-Festplatten mit 15 krpm von 260 IO/s. Dabei hat auch der Festplattencache noch einen Einfluss von bis zu 20%.

Fazit:

Es lohnt nicht, SATA-Festplatten in der PRIMERGY RX100 S4 SAS einzusetzen. Die Performance mit SATA-Festplatten ist identisch zur der Performance der PRIMERGY RX100 S4 SATA.

In Abhängigkeit von der benötigten Performance ist zu entscheiden, ob Festplatten mit 10 krpm oder 15 krpm zum Einsatz kommen sollen. Festplatten mit 15 krpm bieten eine ca. 30% bessere Performance.

Für maximale Performance empfiehlt es sich, den Cache der Festplatten einzuschalten. Je nach verwendetem Plattentyp und Zugriffsmuster liegt die Performance-Steigerung bei bis zu 128%. Bei aktiviertem Festplattencache ist der Einsatz einer USV empfehlenswert.

Benchmark-Umgebung

Alle hier vorgestellten Messungen wurden mit den im Folgenden aufgelisteten Hardware-Komponenten und SoftwareVersionen durchgeführt.

PRIMERGY RX100 S4 SATA

BIOS 1.00a.2532 (2006.09.26) Controller Intel ICH7-R RAID BIOS LSI MegaRAID Software RAID BIOS Version A.01.09111819R Treiber pciide.sys Version 5.2.3790.0 Treiber MegaSR.sys Version 06.04.0721.2006

PRIMERGY RX100 S4 SAS

BIOS 1.03.2532 (2006.11.23) Controller onboard LSI 1068 basierender SAS-RAID Controller IME RAID BIOS LSI Logic MPT SAS BIOS 6.08.0400 (2006.07.13) Treiber lsi_sas.sys Version 1.21.13.00

Software

Betriebssystem Windows Server 2003 R2 Standard Edition Dateisystem NTFS Test-Tool Iometer 2004.07.30 Test-Daten Iometer Messdatei von 8 GB.

Copy Daten von 500 MB

Festplatten

S26361-H978 WD5000KS SATA 7.2 krpm 500 GB S26361-H901 SP2504C SATA 7.2 krpm 250 GB S26361-H909 WD1600JJ SATA 7.2 krpm 160 GB S26361-H899 SPHD080HJ SATA 7.2 krpm 80 GB S26361-H979 ST373355SS SAS 10 krpm 73 GB S26361-H980 ST3146755SS SAS 10 krpm 146 GB S26361-H896 ST336754SS SAS 15 krpm 36 GB S26361-H966 ST373455SS SAS 15 krpm 73 GB S26361-H967 ST3146855SS SAS 15 krpm 146 GB

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Terminal Server

Benchmark-Beschreibung

Für die Messungen von Terminal Server gibt es verschiedene Lastsimulationswerkzeuge, deren Messergebnisse nicht miteinander vergleichbar sind, aber keinen Standard-Benchmark. Die existierenden Lastsimulatoren sind nicht in der Lage, Microsoft Terminal Services und Citrix Presentation Server unter den gleichen Bedingungen zu vermessen oder haben andere Einschränkungen. Fujitsu Siemens Computers setzt daher ein selbst entwickeltes Programm namens T4US, „Tool for User Simulation“, ein. Dieses flexible Werkzeug, das beliebige Terminal Server-artige Szenarien simulieren kann, ist unabhängig vom verwende-

ten Betriebssystem und von der Anwendersoftware und kann eine detaillierte Messwerterfassung von Antwortzeiten und Auslastung unterschiedlichster Systemkomponenten vornehmen.

Benutzeraktivitäten wie Tastatur- und Mauseingaben sowie Bildschirmausgaben können mit Hilfe des Aufzeichnungs-

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

Controller

während der Messung. Auf jedem der Lastgeneratoren laufen mehrere Instanzen des T4US-Playback. Jedes T4USPlayback „füttert“ einen Terminal Server Client in Echtzeit mit Tastatur- und Mauseingaben anhand der mit T4US-Record aufgezeichneten Skripte und überwacht die Bildschirminhalte des Terminal Server Clients. Durch hoch

T4US-

Control

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 arbeitet, kontinuierlich erhöht. Die Antwortzeiten des Terminal Servers werden vom T4US-Controller überwacht und mit gespeicherten Referenzwerten, die in einer vorhergehenden Referenzmessung mit nur fünf 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.

Als Lastprofil dient ein „Medium User“, der nur mit einer Anwendung arbeitet und Daten zügig eingibt. In unserem Medium Lastprofil dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute. Da die Benutzer versetzt gestartet werden, finden während der gesamten Messdauer kontinuierlich An- und Abmeldungen sowie Applikationsstarts statt.

Es hat sich gezeigt, dass viele Messtools, z.B. das früher verwendete CSTK von Citrix, im Vergleich zur Realität zu hohe Benutzerzahlen liefern. In unseren neuen Messreihen haben wir dies berücksichtigt und können daher davon ausgehen, dass die ermittelten Benutzerzahlen denen aus realen Produktionsumgebungen nahe kommen. Bei einer Aussage von absoluten Benutzerzahlen auf einem Server muss trotzdem der kundenspezifische Last-Mix analysiert und mit den Leistungsdaten in diesem Papier in Relation gesetzt werden.

Obgleich das Resultat der Messungen „Anzahl Benutzer pro Server“ ist, sollte man die Ergebnisse in erster Linie relativ betrachten, also beispielsweise „ein PRIMERGY System A ist doppelt so leistungsfähig wie ein PRIMERGY System B“ oder „die Verdopplung des Arbeitsspeichers resultiert in x% Leistungssteigerung“. Die hier gemessene „Anzahl Benutzer pro Server“ gilt für Medium Benutzer, die mit diesem Lastprofil arbeiten. Dieser synthetische Benutzer muss nicht in allen Fällen mit einem realen Benutzer korrelieren.

Nähere Informationen über die T4US-Messumgebung, das Medium Lastprofil und die Resultate der anderen PRIMERGY Modelle findet man im „

Terminal Server Sizing Guide“.

werkzeugs T4US-Record in Echtzeit aufgezeichnet und in einem T4US-Skript gespeichert werden. T4US-Skripte wer- den während der Messung als Lastprofil verwendet.

System under Test (SUT)

Lastgenerator

T4US-

Playback

T4US-

Playback

TS-Client

SUT

…

T4USAgent

T4US-

Playback

TS-Client

Terminal

Server

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Benchmark-Ergebnisse

Für ein Server-System sind die folgenden Performance-relevanten Faktoren maßgeblich:

• Rechenleistung

• Arbeitsspeicher

• Disk-Subsystem

• Netzwerk

Einen erheblichen Einfluss auf die Terminal Server Leistung hat die zugrunde liegende Netzwerkinfrastruktur. Da wir hier die Leistungsfähigkeit eines einzelnen Terminal Servers diskutieren, wurde das Netzwerk so dimensioniert, dass es keinen Engpass darstellt.

Eine weitere performance-relevante Komponente ist das Disk-Subsystem. In der hier verwendeten Messumgebung werden die lokalen Festplatten des Terminal Server Systems für das Betriebssystem, den Pagefile und die Daten der Benutzer verwendet. Dies entspricht jedoch nicht zwingend der realen Kundenkonfiguration, denn dort wird man die Benutzerdaten typischerweise auf entsprechende Disk-Subsysteme oder externe File Server legen und nicht auf die lokalen Festplatten eines Terminal Servers. Aufgrund der Systemeigenschaften der PRIMERGY RX100 S4 wurden die beiden SAS-Festplatten in einem RAID 1 Verband konfiguriert und für Betriebssystem, Daten und Pagefile wurden jeweils eigene Partitionen eingerichtet. Um einen maximalen Durchsatz zu erreichen, wurden alle Caches, auch die WriteCaches, eingeschaltet. 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.

Alle Installationen sind Standard, für die Messungen wurden keine Optimierungen an Server oder Client durchgeführt bis auf:

• Die Page-Datei des Betriebssystems wurde auf eine feste Größe von 4 GB eingestellt.

• Bei Citrix musste die Grenze von 100 Benutzern pro Server, die durch das eingebaute Load Balancing vorgege-

ben wird, aufgehoben werden.

Rechenleistung

Bei der PRIMERGY RX100 S4 kommen, neben dem für Terminal Server ungeeigneten Celeron Prozessor, Intel Pentium D bzw. Xeon Prozessoren zum Einsatz, die mit zwei CPU-Kernen („Dual-Core“), also zwei physikalischen Prozessoren, pro Chip ausgestattet sind. Bei den Pentium D Prozessoren ist der Second Level Cache (SLC) jedem CPU-Kern direkt zugeordnet und hat zurzeit eine Größe von 2 MB pro CPU-Kern. Die Xeon Prozessoren enthalten einen für beide CPUKerne gemeinsamen SLC, der beim Xeon 3040 und Xeon 3050 2 MB bzw. beim Xeon 3060 und Xeon 3070 4 MB groß ist. Auf den Prozessoren, die für die PRIMERGY RX100 S4 angeboten werden, sind 32-bit und 64-bit Betriebssysteme ablauffähig.

Nachfolgend sind die vermessenen Prozessoren mit ihrer Taktfrequenz und Front-Side-Bus-Auslegung spezifiziert:

• Pentium D 3 GHz 2 MB SLC pro Kern 800 MHz Front-Side-Bus

• Pentium D 3.40 GHz 2 MB SLC pro Kern 800 MHz Front-Side-Bus

• Xeon 3040 1.87 GHz 2 MB SLC pro Chip 1067 MHz Front-Side-Bus

• Xeon 3050 2.13 GHz 2 MB SLC pro Chip 1067 MHz Front-Side-Bus

• Xeon 3060 2.40 GHz 4 MB SLC pro Chip 1067 MHz Front-Side-Bus

• Xeon 3070 2.67 GHz 4 MB SLC pro Chip 1067 MHz Front-Side-Bus

In diesem Performance Report wird Terminal Server sowohl unter dem 32-bit Betriebssystem „Windows Server 2003 R2“ als auch unter dem 64-bit Betriebssystem „Windows Server 2003 R2 x64“ untersucht. Die 32-bit und 64-bit Versionen von Windows Server 2003 R2 basieren dabei auf der gleichen Code-Basis und sind daher direkt vergleichbar. Desweiteren ist Windows Server 2003 R2 bis auf einige zusätzliche Dienste und Tools identisch mit Windows Server 2003 Service Pack 1, so dass alle im Folgenden vorgestellten Messergebnisse für alle oben genannte Betriebssystemversionen gelten. Für die 64-bit Messungen wurden die gleichen Randbedingungen verwendet wie bei den 32-bit Messungen. Die simulierten Benutzer arbeiteten in beiden Fällen mit dem Medium Lastprofil unter Verwendung von Microsoft Office 2003.

Die Leistungsfähigkeit der Prozessoren wurde hinsichtlich ihrer Taktfrequenz und Skalierbarkeit unter Terminal Server untersucht.

Bei der Analyse der Rechenleistung waren alle Systeme mit genügend Arbeitsspeicher ausgebaut, damit die Komponente bei diesem Vergleich keinen Engpass darstellt.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Wie man in der unten stehenden Abbildung leicht erkennt, ist die Leistung der Prozessoren im Anwendungsszenario eines Terminal Servers nicht ausschließlich von der Taktfrequenz abhängig. Die Leistungsfähigkeit der Prozessoren ist vielmehr abhängig vom Prozessortyp, der Cache-Größe und der Geschwindigkeit des Front-Side-Busses.

Während die Pentium D Prozessoren auf der älteren Netburst-Architektur basieren, sind die Xeon Prozessoren eine Entwicklung auf der Basis der aktuellen Core Microarchitektur von Intel, die trotz niedrigerer Taktung und geringerem Stromverbrauch eine hervorragende Rechenleistung bietet.

Vergleicht man innerhalb einer Prozessorgeneration die Leistungssteigerung, die sich aus der Erhöhung der Taktfrequenz ergibt, so erkennt man, dass sich die Frequenzsteigerung nicht 1:1 in der relativen Performance-Steigerung widerspiegelt. Dies erklärt sich aus dem gleich bleibenden Front-Side-Bus (FSB) und der somit unveränderten Geschwindigkeit bei Speicher- und I/O-Zugrif-

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

fen. Einen deutlich größeren Einfluss auf die Leistung hat jedoch

die Größe des CPU-Cache, denn durch diesen Cache wird der Front-Side-Bus entlastet. Die Verdopplung des Caches von 2 MB beim Xeon 3050 auf 4 MB beim Xeon 3060 in Verbindung mit einer geringen Frequenzerhöhung von 0.27 GHz steigert die Benutzeranzahl um ca. 15%. Eine Frequenzerhöhung allein trägt hingegen weniger zur Steigerung der Benutzeranzahl bei.

Die absoluten Benutzeranzahlen des 32-bit Systems im Vergleich zum 64-bit System differieren nur im Rahmen der üblichen Messschwankungen.

Beim 64-bit System ist ein größerer Overhead durch die 64-bit breiten Adresszeiger vorhanden. Dies macht sich überall bemerkbar, wo diese Daten gelesen oder geschrieben werden, beispielsweise beim Auslagern von Speicherbereichen. Da mehr Daten verarbeitet werden müssen, hat die Größe des System-Caches einen größeren Einfluss. In Anwendungsszenarien, in denen heute die Einschränkungen der 32-bit Architektur hinsichtlich fehlender interner Betriebssystemstrukturen oder beschränktem virtuellen Adressraum eine Ausnutzung der CPU-Ressourcen unmöglich macht, profitiert man deutlich vom Umstieg auf ein 64-bit Betriebssystem. Bei der PRIMERGY RX100 S4 mit einem Dual-Core Prozessor wird man jedoch selten solche Größenordnungen von Benutzern erreichen, bei denen die Betriebssystemressourcen einen Engpass darstellen. Beim Vergleich des 32-bit Betriebssystems mit dem 64-bit Betriebssystem erkennt man, dass die 64-bit Version bei diesem System eine etwa gleiche Performance liefert wie die 32-bit Version, was zeigt, dass auf der PRIMERGY RX100 S4 auch das 64-bit Betriebssystem sinnvoll und ohne große Leistungseinbußen eingesetzt werden kann. Dieses Ergebnis kann jedoch nicht auf andere PRIMERGY Systeme übertragen werden, gerade bei größeren Systemen mit zwei und mehr CPU-Sockeln hat das 32-bit Betriebssystem im unteren Leistungssegment Vorteile, während im Highendbereich das 64-bit Betriebssystem seine Leistung unter Beweis stellen kann. Eine ausführliche Diskussion von Terminal Server unter x64 findet sich in dem Dokument

Terminal Server Sizing Guide - 64-bit

Technologie (siehe Literaturverzeichnis).

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

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 (Swappen) von momentan nicht benötigten Daten aus dem Arbeitsspeicher (RAM) in die Auslagerungsdatei (Swap-File) 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 bei allen PRIMERGY Systemen linear mit der Anzahl der Benutzer, dies ist auch bei der PRIMERGY RX100 S4 der Fall, wie die zwei Grafiken zum 32-bit- und 64-bit System veranschaulichen. Trägt man den aus „Available MBytes“ berechneten belegten Speicher, den „Committed“ Speicher und das „Working Set“ grafisch auf, so erkennt man einen linearen Verlauf, der mit steigender Benutzeranzahl wächst. Der Anstieg der Geraden ist beim 64-bit Betriebssystem jedoch steiler.

Das 32-bit Betriebssystem (Windows Server 2003 Enterprise Edition mit Microsoft Terminal Services) hat einen Grundbedarf von 128 MB, und pro Benutzer bzw. Client werden weitere 20 MB benötigt. Der Grundbedarf des 64-bit Systems erhöht sich auf ca. 150 MB. In dem Messszenario arbeiten allerdings alle Benutzer mit der gleichen Applikation, daher zeigen alle Benutzergruppen den gleichen Speicherbedarf. Der Speicherbedarf ist jedoch von den verwendeten Applikationen abhängig und muss kundenspezifisch ermittelt werden. Hierbei sollte man beachten, dass die Gesamtleistung des Systems durch die schwächste Komponente bestimmt

wird. Hinzu kommt, dass durch die Architektur des 32-bit Betriebssystems die internen Strukturen und der virtuelle Adressraum eingeschränkt sind. Jedoch trifft dies auf die PRIMERGY RX100 S4 nicht in dem Maße zu wie bei anderen PRIMERGY Systemen, da sie im maximalen Speicherausbau auf 8 GB begrenzt ist.

Insbesondere Anwendungen, die Speicherund nicht CPU-limitiert sind, profitieren von der 64-bit Architektur. Dabei sollte aber 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 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. Die Microsoft Terminal

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

Services liegen als Bestandteil des Betriebssystems in einer 64-bit Version vor.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Da meist der Arbeitsspeicher der limitierende Faktor ist, kann mit der Formel

der benötigte Arbeitsspeicher bei einer vorgegeben Anzahl Benutzer, bzw. die Anzahl Benutzer

bei einer vorgegeben Speichermenge berechnet werden.

Resümee

Das PRIMERGY System RX100 S4 ist ein 1-Socket-Server zum Rack-Einbau, der im Scale-Out-Szenario seinen Platz hat, bei dem eine exzellente Skalierung durch einfaches Hinzufügen weiterer Server erreicht wird. Terminal Server Umgebungen werden in der Praxis als Terminal Server Farm eher auf Basis von 2-Socket-Systemen aufgebaut. Jedoch wird durch die Dual-Core Prozessoren der aktuellen Core-Architektur mit diesem 1-Socket-System eine Leistung erreicht, die in der Vergangenheit Servern mit zwei oder mehr Sockeln vorbehalten war. Die PRIMERGY RX100 S4 kann so als einzelner Terminal Server oder in kleineren Konfigurationen ihr Einsatzgebiet finden.

Folgende Grafik zeigt die PRIMERGY RX100 S4 im Vergleich zu anderen PRIMERGY Systemen. In dieser Darstellung wird die höchste erreichbare Benutzeranzahl jedes PRIMERGY Systems als Maximalwert verwendet, die mit einer optimalen Hardwarekonfiguration und dem jeweils besten Betriebssystem (32-bit oder 64-bit) erreicht wurde. Es gibt keine scharfe Grenze, wo die Leistung eines Modells endet und die des nächst leistungsfähigeren beginnt. Jedes PRIMERGY System deckt eine gewisse Bandbreite ab, wobei es Überlappungen zwischen den Systemen gibt.

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Benchmark-Umgebung

Unten stehende Grafik zeigt die Umgebung, in der die Terminal Server Performance Messungen durchgeführt wurden. Ein Lastgenerator kann eine Vielzahl von Benutzern simulieren, da die Anwendungen auf dem Server ablaufen. Es werden bei den Terminal Server Protokollen nur Tastatureingaben und Mausklicks zum Server und Änderungen des Bildschirminhalts zum Client übertragen. Daher wird keine große Netzwerk-Bandbreite benötigt. Die Anbindung der Lastsimulatoren an den Terminal Server (auch „System under Test“ (SUT) genannt) erfolgte über ein 100-MBit-Ethernet-Netzwerk, wobei der Terminal Server über den Gigabit-Uplink angeschlossen war. Die Benutzerprofile wurden auf dem Terminal Server gespeichert. Auch die Dateien der Benutzer, die während der Messung gelesen und geschrieben wurden, lagen lokal auf dem Terminal Server. Der sich auch im SUT-Netzwerk befindende Infrastruktur-Server stellt dem zu vermessenden Terminal Server Basisdienste wie Active Directory, DNS und Terminal Services Licensing zur Verfügung. Ein Login der simulierten Benutzer fand immer gegen das Active Directory statt.

Controller

für die

Simulation

Simulations-

netzwerk

switched 100 Mbit

PRIMERGY B210

T4US-Control

Jeder simuliert bis zu 30 Benutzer

Lastgeneratoren

> 20 PRIMERGY Dual Server

Windows Server 2003

TS-Client

T4US-Agent, T4US-Playback

System Under Test (SUT):

Der Terminal Server wurde mit den Microsoft Terminal Services betrieben, die im Windows Betriebssystem enthalten sind. Als Terminal Server Anwendung wurde Microsoft Office 2003 verwendet. Auf dem Terminal Server wurde keine weitere Software installiert.

Hardware

Modell PRIMERGY RX100 S4 Prozessor 1 × Pentium D 925, 945 (800 MHz FSB)

1 × Xeon 3040, 3050, 3060, 3070 (1067 MHz

FSB) Speicher 8 GB Netzwerk-Interface 1 × 1 GBit LAN Disk Subsystem 1 × SAS controller (onboard)

2 × Seagate ST373455SS, 73 GB, 10 krpm

Software

Betriebssystem Windows Server 2003 R2 Enterprise Edition

Windows Server 2003 R2 Enterprise x64

Edition Version 5.2.3790 Service Pack 1 Build 3790 Netzwerkprotokoll TCP/IP Disk Organisation 1 × RAID 1 , 1 Partition für das Betriebs-

system, 1 Partition für die Daten, 1 Partition

für das Pagefile Terminal Server

Microsoft Terminal Services Software

Anwendung Microsoft Office 2003 (32-bit) mit SP2

System

under Test

(SUT)

SUT-

Netzwerk

switched 100 Mbit

PRIMERGY

Windows Server 2003

Enterprise Edition

Infrastruktur-

Server

PRIMERGY B210

Windows Server 2003

Active Directory Terminal Server

Licensing Service

T4US Messumgebung:

Die Lastgeneratoren simulieren eine Vielzahl von Benutzern, die mit dem Terminal Server arbeiten. Ein T4US-Controller steuert und überwacht den gesamten Simulationslauf. Der Infrastruktur-Server stellt Basisdienste zur Verfügung.

Lastgenerator-Hardware PRIMERGY L200/P200

# Lastgeneratoren 21 Prozessor 2 × Pentium III 1.27 GHz Memory 1 GB Netzwerk-Interface 2 × 100 MBit LAN

T4US Controller- und Infrastrukturserver-Hardware

Model PRIMERGY C200 Prozessor 2 × Pentium III 1.40 MHz Memory 1.5 GB Netzwerk-Interface 2 × 100 MBit LAN

Software

Betriebssystem Windows Server 2003 Standard Edition SP1 Netzwerkprotokoll TCP/IP RDP Client 5.2.3790.1830 ICA Client 9.00.32649, 32-bit T4US Version 3.3 T4US Lastprofil Medium Lastprofil

White Paper ⏐Performance Report PRIMERGY RX100 S4 Version: 2.2, Juni 2007

Literatur

PRIMERGY Systems http://www.fujitsu-siemens.de/primergy

PRIMERGY RX100 S4 http://www.fujitsu-siemens.de/products/standard_servers/rack/primergy_rx100s4.html

PRIMERGY Performance http://www.fujitsu-siemens.de/products/standard_servers/primergy_bov.html

http://www.spec.org/osg/cpu2000

SPECcpu2000

SPECcpu2006 http://www.spec.org/osg/cpu2006

SPECjbb2005

StorageBench

Benchmark Überblick SPECcpu2000

http://extranet.fujitsu-siemens.de/vil/pc/vil/primergy/performance/Benchmark_Ueberblick_SPECcpu2000.pdf

http://www.spec.org/jbb2005

Benchmark Überblick SPECjbb2005

http://extranet.fujitsu-siemens.com/vil/pc/vil/primergy/performance/Benchmark_Ueberblick_SPECjbb2005.pdf

Informationen über IOMeter

http://www.iometer.org

Disk Subsystem Sizing – RAID Controller

http://extranet.fujitsu-siemens.com/vil/pc/vil/primergy/performance/sizing/disk_subsystem_sizing__raid_controller_1.0__de_.pdf

Terminal Server Sizing Guide (DE)

http://extranet.fujitsu-siemens.com/vil/pc/vil/primergy/performance/sizing/terminal_server_sizing_guide_de.pdf

Terminal Server Sizing Guide - 64-bit Technologie (DE)

http://extranet.fujitsu-siemens.com/vil/pc/vil/primergy/performance/sizing/terminal_server_sizing_guide_-

Terminal Server

_x64_technologie__de.pdf

Microsoft Windows 2003 und Terminal Services

http://www.microsoft.com/terminalserver

Citrix

http://www.citrix.de

Kontakt

PRIMERGY Hardware

PRIMERGY Product Marketing

mailto:Primergy-PM@fujitsu-siemens.com

PRIMERGY Performance und Benchmarks

mailto:primergy.benchmark@fujitsu-siemens.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.

Herausgegeben durch:

Enterprise Products PRIMERGY Server PRIMERGY Performance Lab

mailto:primergy.benchmark@fujitsu-siemens.com

Extranet:

http://extranet.fujitsu-siemens.com/primergy

Internet:

http://www.fujitsu-siemens.de/primergy

Siemens RX100 S4 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Technische Daten

StorageBench

Terminal Server

Literatur

Kontakt