Seit heute gibt es tatsächlich einige Resultate zum neuen SAP-SD-2tier-Benchmark. Und in meinem anderen Posting habe ich ja schon angekündigt, mich ein wenig intensiver mit den Änderungen bei SAPS und User zu beschäftigen, um ein wenig Klarheit ins Dunkel zu bringen. Wobei eine Einschränkung gilt: Ich beschäftige mich nicht vom Hauptberuf her mit Benchmarking, da gibt es berufenere und fähigere Leute als ich.
Was ändert sich nun durch den neuen Benchmark, der gerne mit dem Kürzel „EHP 4 unicode“ abgekürzt wird?
1. Das SAP Release ist auf das Enhancement Package 4 gehoben worden: Dazu muss man verstehen, dass der SD-Benchmark ein funktionierendes SAP-ERP-System als Basis nutzt – auf einem SAP-ERP wird immer wieder die gleiche Aktionen durch viele User durchgeführt. Diese Aktionen spielen sich alle im Bereich Sales & Distribution ab, daher der Namesbestandteil „SD“. Dieses System erfuhr nun ein „Upgrade“ auf die aktuellste Version, die den Name „ERP 6.0 EHP 4“ trägt.
2. Das Customizing wurde verändert. Jetzt auch noch in die Untiefen des ERP hinein schauen? Ist notwendig: Der General Ledger, das Hauptbuch der Buchhaltung im ERP-System, wurde auf eine neuere Variante gehoben. Das bedeutet mehr Arbeitsschritte, aber auch eine exaktere Simulation. Zudem wurde die Prüfung der Kreditwürdigkeit hinzugenommen. In realen Systemen ist diese meistens auch aktiviert, daher erhöht auch dies den Realitätsgrad des Benchmarks.
3. Unicode als Codepage wurde vorgeschrieben, wie auch schon für neue Installationen oder seit je her für den Java-Stack.
4. Die maximale zulässige Antwortzeit wurde auf 1 Sekunde gesenkt.
Welche dieser vier Maßnahmen hat nun welche Auswirkungen?
1. Das Enhancement Package 4 dürfte nur wenig Auswirkungen haben. Wie der Name schon sagt, erweitert es streng genommen nur die Funktionen, welche im ERP-System vorhanden sind, um neue. Es ist nicht ausgeschlossen, dass die ein- oder andere Funktion durch das EHP verändert wird, um neue Funktionen zu integrieren. Selbst wenn die neuen Funktionen nicht genutzt werden, so ist schon davon auszugehen, dass EHP 4 das System geringfügig „hunriger“ macht.
2. Das neue Customizing dürfte richtig Leistung kosten: Das veränderte Hauptbuch und die hinzugekommene Kreditwürdigkeitsprüfung werden ihren Tribut verlangen, ich würde mit 10% rechnen, vielleicht sogar mehr.
3. Unicode, der Dauerbrenner. Es wurde eigentlich schon alles gesagt. 15% im Schnitt. Auf manchen Systemen mit schmalbandiger Speicheranbindung oder bei Betriebssystemen mit merkwürdigen Unicode-Implementierungen mehr.
4. Kürzere Warteschlange. Ein schwieriges Thema, bei dem man ein wenig ausholen muss. Zunächst die Frage, ob überhaupt ein Impact da ist: Der SD-Benchmark misst den Durchsatz, wie viele Orderline-Items in einem Zeitintervall verarbeitet werden. Die User sind – vereinfacht ausgedrückt – hiervon direkt abhängig, da jeder User eine vergleichbare Last für das System darstellt. Natürlich gibt’s da ne Schwankung in der Verarbeitungszeit, da jeder User nur eine ähnliche, nicht aber die identische Last bedeutet. Diese Schwankung schlägt sich in der Warteschlange und der dort verbrachten Zeit nieder (Dort geht übrigens die meiste Zeit ‚drauf, die Prozessorzeit ist nur ein Bruchteil der Gesamtzeit). Nun ein wenig Warteschlangentheorie: Je länger die Warteschlange, desto höher wird die durchschnittliche Auslastung des Prozessors, und desto mehr Transaktionen wird er in einer Zeiteinheit abarbeiten können (nicht weil er schneller wäre, sondern weil genügend Arbeit da ist!)
Nun bedeutet eine Halbierung der Warteschlangenlänge nicht zwangsläufig eine Halbierung der Auslastung. Wenn die Warteschlage eh schon hoffnungslos zu lang ist, wird eine Halbierung zwar die Durchlaufszeit fast halbieren, nicht aber die Auslastung. Dennoch: Bereits bei den aktuellen Benchmarks fällt die Auslastung der gleichen Maschine (die beiden HP-Benchmarks 2009004 und 2008071) um etwa eine Prozentpunkt. Zusammen mit dem Wissen um die veränderte Last, die der Prozessor hat, ergibt sich daraus ein Einfluss irgendwo zwischen 2% und 6%, den die Warteschlange auf den Durchsatz haben dürfte.
Hinzu kommt noch ein Nebeneffekt: Die Last wird nicht an einem System gemessen, sondern 1000 User teilen sich je ein ERP-System. Die Zeiten werden gemittelt. Meine benchmarkenden Kollegen beobachten häufiger eine ungleiche Verteilung der Warteschlangenlängen. Im Mittel kam man dann auf die geforderten 2 Sekunden beim alten Benchmark, allerdings mit realen Zeiten zwischen 1 und mehr als 2 Sekunden. Man konnte mit einer 1-Sekunden-Warteschlange eine 3-Sekunden-Schlange „wegmitteln“. Das wird nun schwieriger. Um eine 2-Sekunden-Schlange wegzumitteln, benötigt man gleich 2 0,5-Sekunden-Schlangen.
Zusammenfassend kann man sagen: Die neue Version des SAP-SD-2tier-Benchmarks passt den Benchmark an die Realität an. Dabei haben Unicode und die Anpassungen im Customizing großen Einfluss auf die Last. Weniger spielen die Warteschlangenlänge und die neue Version eine Rolle. Letztendlich bleiben die Resultate vergleichbar, ein erster Umrechenfaktor lässt sich bestimmen (hier mal ein Dank an HP!).