Thoughts. Ideas. Photography.

Posts tagged “Benchmarketing

Perfect? Not really….

In summer, I had an interesting conversation with a colleague of mine, Jörg Möllenkamp. We analyzed performance numbers of IBMs 795 systems IBM published and were sure the numbers were a bit too perfect. Jörg mentioned this in his blog.

So it is time for a quick review of IBMs scaling. They have published their „really-big-iron“ benchmark results in the last weeks.

Let’s have a look:

  • IBM 795, 32 CPU, 4 TB RAM: 688630 SAPS (Certificate 2010046)
  • IBM 795, 16 CPU, 2 TB RAM: 384330 SAPS (Certificate 2010042)
  • for more benchmark results, please click on the certificate links. I will focus on SAPS in this article, if you prefer SD Users please check the certificates

Well, on the first view, both results are very impressive.  I have never ever seen a customer who needs such a power „in one piece“. But maybe IBM can find one. Good luck!

But I’m also interested in scaling factors: How much performance can I get if I double the CPUs of the overall system? And this factor includes more than only some CPU power, it also includes overhead for interconnecting, for memory access etc.

Okay… IBM doubled the number of CPUs/cores and… the SAPS went up by 1,79. Is this a good scaling factor?

Well, let’s compare this to other scaling factors. SPARC64 on M9000 with Oracle Database and Intels Nehalem-EX architecture and Oracle RAC. Oracle RAC realizes so called scale out, while large SMP systems like IBMs 795 or the M9000 scale up in the same box. In most cases, scaling out depends on a fast interconnect between the systems, while scaling up depends on a well scalling OS and a fast interconnect between all CPUs of the system. I also included a scale up comparison with Nehalem EX.

So, what are realistic scaling factors

Nehalem EX / Oracle RAC (scale out):

Nehalem EX / MS SQL (scale up)

SPARC64VII / Oracle 10g (scale up)

Power7 / DB2

In my opinion, this shows two important facts:

  1. Scale out and scale up are never perfect. You will always get some „penalty“ for having more than one simultaneous thread running.
  2. The mean value in my little, no representative calculation is around 1.82 – 1.83. So being above this value suggests a good scaling factor.

There also a little indication that scaling out performed better on x86 than scaling up. I don’t want to say it is better on RISC, because I did not found benchmark results using RISC and RAC at once.

At least, this figures show one thing we have expected:  IBM, the perfect linear scaling you claimed in summer is … not reached yet. Maybe you should start to build a better system for your world class CPU.


Schlanke Virtualisierung

Wieviel Leistung kostet Virtualisierung? Es gibt jetzt zwei SAP SD-2tier-Benchmarks, mit denen man zumindest ein Gefühl für die Beantwortung dieser Frage bekommen kann:

2009034: Sun Fire x4270, Solaris 10, Solaris Container as Virtualization, 8vCPUs (half the CPUs available in the box), Oracle 10g, EHP4: 2800 SD-User.

2009029: Fujitsu Primergy RX 3000, SuSE Linux Enterprise Server 10, VMWare ESX Server 4.0, 8vCPUs (half the CPUs available in the box), MaxDB 7.8, EHP4: 2056 SD-User.

Vereinfacht: Zwei „halbe Nehalem-Boxen“.

Dann interpretieren wir mal:

Zunächst: Dank Intels Hyperthreading kann man nicht einfach von der Leistung einer halben Box auf die ganze Box schließen: Hyperthreading bedeutet, dass bei 8 vorhandenen Kernen bis zu 16 Threads simultan abgearbeitet werden. Das bedeutet aber nicht, dass der jeweils zweite Thread die gleiche Auslastung erreicht wie der erste. Daher sind die Resultate durchaus im erwarteten Rahmen.

Als zweiter Punkt: Ja, VMWare nutzt Linux und Sun Solaris. Logisch – beide mussten ein OS nutzen, das seitens SAP für die jeweilige Virtualisierungstechnologie freigegeben ist. Und ja, ich hab auch schon darüber geschrieben, dass Solaris bei gleicher Hardware im SD-Becnhmark mehr leistet als Linux. Aber: Das sind rund 36% Unterschied hier, mehr als ein Drittel. Das kann man nicht alleinig dem Linux zuschreiben. Da war mehr im Spiel – die Virtualisierung hat definitiv einen nicht unerheblichen Einfluss gehabt.

Wieviel „Penalty“ hat denn nun der VMWare Hypervisor, oder wieviel Vorsprung haben denn nun die Solaris Container? Das ist schwierig zu beantworten. Nimmt man an, dass Linux und Windows im neuen EHP4-Benchmark vergleichbar gut sind, dann ist der Solaris-Vorsprung irgendwo zwischen 15 und 20%. Den Rest darf jeder Selbst errechnen.


Der neue SAP-SD-2tier-Benchmark

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!).


Äpfel und Birnen – nee, Äpfel und Äpfel

Es gelten neue Benchmark-Regeln im SAP-SD-Benchmark, und seit dem kann man die Resultate endlich besser vergleichen. Unicode wurde Pflicht, das Customizing hat sich verändert. Alles in allem scheint der Benchmark zu seiner Vorversion etwa einen „Umrechnungsfaktor“ von 0.7 zu haben.

Der Umrechnungsfaktor errechnet sich folgendermaßen: HP und Fujitsu haben im Dezember letzten Jahres bereits Benchmarks mit Nehalem-Prozessoren veröffentlicht. Damals erreichte HP rund 25.000 SAPS (ECC 6.0 non-unicode) und 4995 SD-User (Zertifikat 2008071). Heute erreicht HP auf identischer Hardware und weitestgehend identischer Software 18030 SAPS (EHP 4, unicode) und 3300 User (Zertifikat 2009004). Somit gilt für die SAPS ein Faktor von etwa 0.72, für die User von 0.66. Wieso die User stärker betroffen sind als die SAPS-Werte, ist auf die neuen Parameter und eine kürzere Warteschlange zurückzuführen. Dazu sollte ich auch mal bloggen…

So oder so. Natürlich gab’s auch einen Benchmark von Sun auf einer vergleichbaren Maschine. Und siehe da: 20300 SAPS (EHP4 unicode) und 3700 User (Zertifikat 2009005), also rund 11-12% mehr SAPS und User.

Woran das liegt? Es wäre Spekulation, hier detailliert 2% hier oder 5% dort zuzuweisen. Die Benchmarks nutzen zwar weitgehend identische Hardware, doch wird es Unterschiede im Detail geben. Doch vor allem  ist klar, dass ein großer Teil der besseren Performance dem Betriebssystem zuzuschreiben ist, wie es schon bei dem ein oder anderen Ergebnis zu sehen war. Der Einfluss der Datenbank ist zwar vorhanden, doch nicht unbedingt so groß, da der Benchmark applikationszentrisch ist.


Äpfel und Birnen, reloaded

Neues aus dem Bereich Benchmarking. Die beiden 8-Sockel-Kontrahenden waren im Training und sind auf 2,7 GHz hochgerüstet worden. HP hat zusätzlich noch das Betriebssystem und die Datenbank getauscht. Also geht der Kampf vom letzten Mal in die nächste Runde

Nochmal im Kontrahenden:

In der Sonnigen Ecke: Sun Fire X4600M2 mit 32 Cores, verteilt auf 8 Prozessoren, die mit 2,7 GHz ihre 32  Threads abarbeiten. Dazu 128 GB RAM, Solaris 10, MaxDB 7.6, ECC 6.0 unicode.

Und aus der Garage der Erfindungen kommt: HP Proliant 785 G5 mit 32 Cores, verteilt auf 8 Prozessoren, die mit 2,7 GHz ihre 32  Threads abarbeiten. Dazu 128 GB RAM, Suse Linux und Oracle 10g, ECC 6.0 non-unicode.

Das Endergebnis: Sun Fire X4600M2 liefert 39370 SAPS (Zertifikat 2008070, entspricht 7850 SD-User), der Proliant 785 G5 kommt auf 35.400 SAPS (Zertifikat 2008064, entspricht 7010 SD-User). Über den Einfluss von Unicode muss ja nichts mehr gesagt werden.


Äpfel und Birnen, nächste Runde

Der SAP-SD-Benchmark ist schon herrlich. Hat was von Boxkämpfen. Letzte Woche gab es einen Kampf im Schwergewicht der x86-Klasse.

  • In der sonnigen Ecke: Sun Fire X4600M2, 8 Prozessoren, 32 Cores, 32 Threads, Quad-Core AMD Opteron 8360 SE, 2.5 GHz, 128 GB RAM
  • In der staubigen Hinterhofgarage aka Invent-Garage: HP ProLiant DL785, auch 8 Prozessoren mit 32 Cores, 32 Threads, Quad-Core AMD Opteron 8360 SE, 128 GB RAM

(Gut, ich hätte auch schreiben können: Identisch ausgestattete 8-Core Opteron-Maschinen von HP und Sun.)

Die Kontrahenden legen beide los und messen sich im Abfertigen von SD-Usern. Die X4600M2 erreicht schwitzend 5.800 SD-User (entspricht 29. 670 SAPS, siehe Zertifikat 2008061). Der räumlich größere ProLiant macht schon bei 5.230 SD-Usern schlapp (das sind 26.180 SAPS siehe Zertifikat 2008026). Sieg nach Punkten eindeutig für Sun. Die X4600M2 ist die schnellste 8-Sockel-x86-Maschine.

Der ProLiant hat zwar das gleiche Kampfgewicht, doch kämpft er mit anderen Bandagen. Während Die X4600M2 multikultikompatibel mit einem Unicode-Benchmark antritt, beschränkt sich der HP auf non-unicode. Liebe HP, verwendet doch auch mal Unicode. Klar, das kostet rund 15% der Punktzahl, dafür ist es dann aber eher vergleichbar.

Ebenfalls nicht Identisch: Die Betriebssysteme und die Datenbanken. Solaris vs. Windows, MaxDB vs. MS-SQL. Womit wir bei der nächsten Frage wären: Wie hoch ist der Einfluss des Betriebssystems und der Datenbank auf den Benchmark? Von der SAP gibt es dazu leider nichts eindeutiges, und ich habe auch keinen Benchmark der gleichen Maschine mit Windows und Unix auf die Schnelle gefunden. Persönlich würde ich den Einfluss von OS und DB nicht unterbewerten wollen. Dennoch kann man nicht mit Bestimmtheit sagen, ob es jetzt an HP oder an Microsoft liegt, dass die HP-Maschine zwischen 10% und 25% langsamer ist als die von Sun.

Naja, mal wieder Äpfel und Birnen im direkten Vergleich.


Äpfel und Birnen im direkten Vergleich

Sonntags auf Heise:

Bei den Vierprozessorsystemen konnte sich HPs ProLiant DL580 G5 mit Windows Server 2003 und Microsoft SQL Server 2005 mit 5155 SD-Usern(1,97 s, 25.380 SAPS) klar vor Suns Fire X4450 mit Solaris 10 und MaxDB 7.6 behaupten, das nur auf 4600 SD-User (1,94s, 23120 SAPS) kommt. Nur knapp dahinter ist schon der mit dem energiesparenden Xeon E7450 bestückte HP ProLiant BL680c G5 zu finden, der 4432 SD-User (1,99s, 22.180 SAPS) bedienen kann.

Äpfel und Birnen in einem direkten Vergleich.

Der SAP-SD-Benchmark existiert in verschiedenen Versionen. Welche Version genutzt wurde steht in den Benchmark-Tabellen der SAP. So verwendet eine Variante Unicode, die andere nicht. Es ist logisch, dass die erstgenannte Version mehr Last darstellt, und dass identische Maschinen bei Verwendung des Unicode-Benchmarks kleinere Werte erreichen als beim Non-Unicode-Benchmark. Üblicherweise liegt die Mehrlast eines Unicodesystems bei aktuellen CPUs rund 15% höher als bei Non-Unicode.

Die beiden HP-Benchmarks sind direkt vergleichbar: beides sind Non-Unicode-Benchmarks.

Der Sun-Benchmark ist ein Unicode-Benchmark.

Immerhin kann man sagen: Sun hat den schnellsten Unix-4-Prozessoren-6-Kern-x86-Server.