Abgestempelt

Inhaltsverzeichnis

Hauptaufgabe der Systems Performance Evaluation Corporation (SPEC) ist es, Benchmarks sowie Test-Suites zusammenzustellen, die Software herauszugeben und zu pflegen, die Resultate zu prüfen und zu veröffentlichen. Zur Vereinigung gehören namhafte Systemhersteller und Softwarehäuser wie Fujitsu, HP, IBM, Intel, Oracle, Citrix, Red Hat, SUSE und VMware, um nur einige der an die fünfzig Mitglieder zu nennen. Hinzu kommen noch fast 30 assoziierte Mitglieder und rund 50 Forschungslabore, die sich mit der Entwicklung befassen.

Nach Jahren hat die für Server zuständige Open Systems Group (OSG) eine neue Version ihres Java Business Benchmarks (JBB) herausgegeben. Seit Oktober 2013 ist die bisherige Benchmark-Version JBB2005 nicht mehr gültig, deren Ergebnisse sind aufgrund maßgeblicher Änderungen mit denen des neuen JBB2013 nicht vergleichbar.

Gleich geblieben ist das Prinzip: Das Programm simuliert den Ablauf des Warenverkehrs in einem weltweit handelnden Supermarkt von den Bestellungen über den Wareneingang und -umschlag bis hin zur Auslieferung. Mit der neuen Version sind Aspekte wie Data Mining, Point of Sale und der Onlinehandel hinzugekommen.

Außerdem haben die Entwickler die Struktur der Suite grundlegend geändert. Sie besteht aus drei Bereichen:

– dem Controller (Ctr), dem Aufpasser, der den Benchmark steuert,

– dem Transaction Injector (TxI), sozusagen dem Auftraggeber, der die Lasten auf die Testsysteme verteilt und

– dem Backend (BE), das die Geschäftslogik enthält und die Transaktionen, sprich den Betrieb, abwickelt.

Neue Version greift deutlich weiter

Damit ist der JBB2013 um einiges mächtiger als sein acht Jahre alter Vorgänger. Denn die drei Ebenen lassen sich auf getrennten Systemen, sogar mit unterschiedlichen Java-Maschinen unterbringen, sodass der Tester sowohl einen einzelnen Server als auch ganze Farmen von Servern untersuchen kann.

Während der Controller nur einmal als Instanz vorkommt, können TxI und BE mehrfach angebunden sein. Letztere bilden jeweils eine Gruppe, wobei bis zu zwei Injectors ein Backend mit Aufträgen versorgen dürfen. Die Dreiteilung erlaubt es, für jede Ebene eine eigene Java-Maschine in Gang zu setzen, wobei die BEs selbst in allen Gruppen homogen sein müssen: Es darf dort nur dieselbe Java-Maschine laufen. Entscheidend für die Performance-Messungen sind die Backends, die auf dem System Under Test (SUT) laufen.

Zur Geschäftslogik dort gehören nicht nur Supermärkte und Kunden, sondern neuerdings eine Zentrale pro Gruppe. Das sogenannte Headquarter (HQ) verwaltet die Kundendaten und führt Datenanalysen durch. Der neuen Struktur entsprechend gibt es drei Testvarianten:

– Composite ähnelt dem früheren Verfahren. Es läuft eine einzige Java-Maschine auf einem System, somit existiert nach oberer Lesart nur eine Gruppe.

– MultiJVM bedeutet, dass mehrere Instanzen des JRE laufen dürfen, das heißt, dass mehrere Gruppen aktiv sind. Beim Vorgänger gab es ebenfalls eine Methode, mehrere JRE zu betreiben, deren Zahl sich an der der CPUs-Chips orientierte.

– Distributed heißt, dass mindestens zwei Systeme vorhanden sind, auf die sich die Gruppen verteilen. Eine Control-Instanz startet und überwacht den Lauf auf mehreren Maschinen. Das Verfahren ist neu und berücksichtigt Situationen in der Realität, bei denen die Geschäftsprozesse auf Clustern laufen.

Maßeinheiten grundlegend geändert

Als Endergebnis liefert der JBB2013 Java Operations per Second (jOPS) und unterscheidet sich schon allein dadurch vom Vorgänger, der „Business Operations per Second“ (bops) als Maßeinheit verwendete. Zudem liefert der neue Test zwei Resultate: max-jOPS und critical-jOPS. Im ersten Fall beschreiben sie, nach dem schrittweisen Erhöhen der Last, das erreichte Maximum des SUT, bevor der erste Fehler auftritt, sprich das Wiederholen einer Transaktion fehlschlägt.

Komplexer sind die Methoden zum Ermitteln des neuen zweiten Wertes, den critical-jOPS. Dort geht es um Antwortzeiten, mit denen der Test Service Level Agreements (SLAs) ins Spiel bringt. Es handelt sich um das geometrische Mittel der Werte, die das SUT bei den Reaktionszeiten (SLA-Levels) von 10 ms, 50 ms, 100 ms, 200 ms und 500 ms erreicht.

Dementsprechend umfangreich sind die Dokumente, die zum JBB2013 gehören. Für das einfache Vergleichen von Systemen sicherlich zu viel des Guten, für Entwickler, Systemdesigner und -betreiber aber ein differenzierbares Werkzeug zur Analyse von Installationen.

Ein einfacher Composite-Report umfasst 2,25 MByte verteilt auf 18 Dateien in zehn Ordnern. Er braucht gut zweieinhalb Stunden. Wer auf der SPEC-Site einen Blick in das Ergebnisdokument eines der getesteten Systeme wirft, dürfte schnell erkennen, dass sich das zum Veröffentlichen in einem Testbericht nur in Auszügen eignet.

Die Java Business Benchmarks der SPEC spielen eine besondere Rolle, da die OSG das Verfahren sowohl für den SPECpower_ssj2008, den Energietest als auch für das Server Efficiency Rating Tool (SERT) zum Klassifizieren von Servern zugrunde legt. Auftraggeber für SERT war die US Environmental Protection Agency (EPA), die das Werkzeug als Ausgangsbasis für den Energy Star in dieser Kategorie verwendet.

Fazit

Mit der neuen Version des jbb2013 hat die OSG der SPEC eine umfangreiche Testsuite vorgelegt. Die technischen Voraussetzungen sind moderat: eine Maschine mit mindestens 24 GByte Hauptspeicher für die Performance-Messungen und ein Java Development Kit (JDK), das Java 7 unterstützt. Zum Durchführen des JBB bedarf es einer JVM.

Gedacht sind die Benchmarks der SPEC für den Einsatz in der Industrie, dort vor allem bei den Systemherstellern und Anbietern. Einige, etwa der Prozessor-Benchmark SPEC CPU2006, zählen oft zu den Kriterien für Ausschreibungen. Der überwiegende Teil der 18 aktuellen Suites ist kostenpflichtig. Die Preise liegen zwischen 495 und 5000 US-$ für den kommerziellen Einsatz. Für die nicht geschäftliche Verwendung gibt es Preisnachlässe.

Alle Links: www.ix.de/ix1402124 (rh)