Skalierbare Leistungsträger

Umfangreiche Testszenarien

Um einen ersten Anhaltspunkt über die zu erwartenden Leistungen der Kandidaten zu erhalten, führten wir zunächst einen Performance-Test von Plattensubsystem, Hauptspeicher und CPU durch. Dafür verwendeten wir das Freeware-Tool "Nbench". Bei der CPU interessierte uns sowohl die Integer- als auch die Gleitkommaleistung, die Nbench in Millionen Operationen pro Sekunde (MOPs/s) angibt. Für den Integer-Test verwendet das Tool ein Programm, das kontinuierlich einen Satz von 1000 ganzzahligen Werten sortiert. Den Gleitkommadurchsatz testet es mithilfe einer Reihe von Gleitkommberechnungen, für die es die Grundrechenarten Addition, Subtraktion, Division und Multiplikation einsetzt.

Die Festplatten-Performance ermittelt Nbench mithilfe einer Routine, die eine Datei sequentiell schreibt und anschließend wieder einliest. Um hierbei ein Caching durch das Betriebssystem zu unterbinden, legt Nbench die Datei mit dem Attribut FILE_NO_BUFFERING an. Da jedoch Raid-Controller über eigene Caches verfügen, setzten wir mit 999 MByte eine Dateigröße an, bei der auch der 128 MByte große Cache des Mylex-Raid-Controllers im Primergy N400 keine Chance zum "Schummeln" hatte. Für den Performance-Test des Hauptspeichers entschieden wir uns für eine Region oberhalb von 4000 KByte, die somit ausreichend weit über der 2048-KByte-Region des SLC lag.

Zur Messung der Datenbank-Performance wählten wir "Benchmark Factory 3.0" von der Firma Quest Software. Das Produkt bietet umfangreiche Möglichkeiten, um Server in einer verteilten Umgebung mit einer Kontrollstation und mehreren Agenten unter verschiedenen Lastbedingungen zu testen. Neben Datenbank-Benchmarks enthält Benchmark Factory auch Tests für Webserver, Mailserver und File-Server. Bei der Datenbank entschieden wir uns passend zum Betriebssystem für den "Microsoft SQL Server 2000" in der Enterprise-Version. Da wir nicht die SQL-Server-Software testen wollten, sondern die zu Grunde liegende Hardware, verzichteten wir bei Installation und Konfiguration der Datenbank auf jegliche Tuningmaßnahmen. Wir verwendeten die Standardeinstellungen; lediglich den Pfad für die SQL-Server-Daten legten wir nicht auf die Systemplatte, sondern auf unser Datenlaufwerk.

Somit war die Vergleichbarkeit der Ergebnisse gewährleistet. Jeder Server wurde sowohl in einer Konfiguration mit zwei als auch mit vier CPUs getestet. Als Benchmark kamen der in Benchmark Factory integrierte "DBSpec94 Iterative Update Mix" und der "DBSpec94 Iterative Read Mix" zum Einsatz, die beide bereits mit wenigen virtuellen Benutzern eine sehr hohe Last generieren.

Der DBSpec94 Iterative Read Mix verwendet dazu eine Variation von verschiedenen Testskripten, die jeweils mit einer Gewichtung versehen sind. Innerhalb eines Iterationsschrittes wird jedes Skript mit der Häufigkeit der vorgegebenen Gewichtung ausgeführt. Das Testskript "ir_1" beispielsweise, hinter dem sich das SQL-Statement "SELECT DB94key, DB94code, DB94date, DB94signed, DB94name FROM DB94_updates WHERE DB94key = RandomInteger" verbirgt, wird mit einer Wahrscheinlichkeit von 30 Prozent innerhalb einer Iteration abgearbeitet.

Beim DBSpec Iterative Read Mix erfolgen ausschließlich lesende Zugriffe auf die Datenbank. Die Leis-tungsfähigkeit der CPU und des Hauptspeichers sind hierbei besonders gefragt, da der SQL-Server die angeforderten Daten weitgehend aus dem Hauptspeicher des getesteten Systems liest. Beim DBSpec94 Iterative Update Mix werden neben SELECT-Statements auch UPDATE-Anweisungen durchgeführt. Dies hat zur Folge, dass neben der Leistung der CPU und des Hauptspeichers auch die der Plattensubsysteme in die Wertung mit einfließt. Ähnlich wie beim"Read Mix" führt auch der "Update Mix" eine Reihe unterschiedlicher Skripte aus, jeweils mit einer individuellen Gewichtung innerhalb einer Iteration.

Die Abarbeitung sämtlicher Skripte wählten wir so, dass keinerlei Latenzzeiten innerhalb einer Iteration entstehen konnten. Zwischen mehreren Iterationen stellten wir jedoch eine Rampup- und Rampdown-Periode von jeweils 15 Sekunden ein, um Laufzeitunterschiede zwischen den verschiedenen Agent-Testsystemen auszugleichen. Benchmark Factory wurde zudem so konfiguriert, dass mit jeder Iteration die Zahl der virtuellen Benutzer zunimmt. Die Tests begannen mit einem Benutzer und steigerten sich von fünf auf zehn Benutzer. Von da an ging es in Zehnerschritten bis maximal 70 Benutzer. Diese Anzahl war mit den gewählten Skripten und Parametern vollkommen ausreichend, um die Grenzen der Systeme auszuloten.

Der Testaufbau bestand aus insgesamt zehn Client-Systemen. Auf neun waren Benchmark-Factory-Agents installiert, die für Last sorgten. Ein Rechner fungierte als Kontrollzentrum, das die Agenten steuerte und nach jeder Iteration die Messergebnisse einsammelte. Die Clients waren per 100Base-TX-Verbindung mit einem "DES-3326"-Switch von D-Link verbunden. Die Anbindung der Testkandidaten erfolgte per Gigabit-Ethernet entweder über eine 1000Base-SX- oder 1000Base-TX-Verbindung an einem Gigabit-Ethernet-Uplink-Port des D-Link-Switches.

Die Gigabit-Ethernet-Anbindung stellte sicher, dass die Netzwerkverbindung nicht zum Flaschenhals werden und die Messergebnisse verfälschen konnte. Die zu testenden Server und der Kontrollrechner waren zudem an einem "Ultraview Pro KVM"-Switch von Rose angeschlossen, der ein reibungsloses Umschalten zwischen den Systemen ermöglichte.