Archive for the tag 'SD-Benchmark'

Perfect? Not really….

Jan November 17th, 2010

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 M900 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.

Tags: , ,

Es liegt vor allem an Solaris…

Jan Januar 26th, 2010

Jetzt gibt es den neuen SAP-SD-2tier-Benchmark seit etwa einem Jahr. Auch wenn dieser Benchmark nicht für jeden ITler von Bedeutung ist, so ist er für meine Projekte sehr zentral. Er ist im SAP-Umfeld der Standard, und er ist zentral für  Sizings und Architekturen.

Es gab tiefgreifende Änderungen zu Beginn des Jahres gegenüber dem vorhergehenden Benchmark, die Benchmarkteams mussten sich erst auf diese Veränderungen einstellen. Alles in allem ein spannendes Jahr.

Nachdem im Jahr 2009 rund 40 Ergebnisse veröffentlicht wurden, ist es also Zeit für ein kleines Resümee. Was fällt also so auf?

  • Eine wirkliche Aussage, wieviel mehr “Last” der neue Benchmark bedeutet, oder wie der “Umrechnungsfaktor ist”, ist immer noch kaum möglich. Es gibt sehr viele Benchmarks mit Intel Xeon und AMD Opteron, aber außer ein paar SPARC- und einem einzelnen Power-Ergebnis ist es recht ruhig um die RISC-Architekturen. Also weiter die Vermutung Irgendwo zwischen 25 und 35% wird er wohl liegen.
  • Vor allem drei Änderung, und zwar der Unicode-Zwang, das neue Hauptbuch und die erweiterte Kreditoren-Prüfung, sorgen für weitere Prozessschritte. Diese Änderungen sorgen für eine reale Mehrlast auf den Prozessoren der Systeme. Mehr Speicher bringt dabei nicht unbedingt was, die Rekorde auf 48GB zeigen.
  • Eine Änderung sorgt für lustige Warteschlangen-Effekte: Durch die Verkürzung der Antwortzeit von zwei auf eine Sekunde verkürzt sich die Wartezeit, die ein Auftrag im System verbringen darf. Folglich verkürzen sich vor allem die Warteschlangen, und hier schlägt dann die Warteschlangentheorie zu. Je mehr simultane Verarbeitungen möglich sind, desto eher kommen erstaunlich niedrige SAPS-Werte heraus. Kann man mit einem Warteschlangensimulator mal nachspielen.

Okay, das waren sehr generelle Auffälligkeiten. Nun ein paar Anmerkungen zu einigen Resultaten (die ich hier noch nicht diskutiert habe).

Schaut man auf das Feld der Benchmarker, fällt einer nicht auf: IBM. Ich habe mit unseren Benchmarkern mal diskutiert, warum IBM sich im 2-tier-Benchmark so bedeckt hält, aber statt dessen beispielsweise recht viele BI-XML-Benchmarks machen. Das erschwert den Vergleich – die Lasten sind recht unterschiedlich, an ein umrechnen ist nicht zu denken. Warum macht IBM nicht den “Standard-Benchmark” und statt dessen diesen Exoten? Ich vermute mal, es liegt an ihrem Hang zum Paritionieren: Im SD-Benchmark sind Datenbank und Applikationsserver nicht voneinander getrennt. Doch wenn man trennen will, beispielsweise mit LPARs, weil man aus irgendeinem Grund nicht gut über die gesamte Maschine skaliert oder mehr Kontrolle über die Aufteilung der Ressourcen braucht, um gute Resultate zu erziehlen, dann muss man das seit diesem Jahr als einen 3-tier-Benchmark ausweisen. IBM, bekommt ihr die vielen SAPS eine p595 etwa nicht “am Stück” auf die Straße?

Als zweites fällt die extreme Dominanz eines einzelnen Prozessors auf: Der Intel Xeon 5570, aka. Nehalem 2,93GHz, ist praktisch in jedem zweiten SD-Benchmark vertreten. Angeblich sind die Maschinen sehr sehr ähnlich, Resultate können fast immer auf die Software zurückgeführt werden. Im Dezember wurde dieser Glaube ein wenig erschüttert. Doch fangen wir langsam an.

Zunächst der ceteris-paribus-Beweis, dass Solaris mehr aus der Hardware rausholt als Windows:

  • Zertifikat 2009048: Sun Fire X4270, 2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 48 GB main memory, Windows 2008 Server & MS SQL-Server 2008: 3.416 User, 18.730 SAPS.
  • Zertifikat 2009033: Sun Fire X4270, 2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 48 GB main memory, Solaris 10 und Oracle 10g: 3.800 User, 21.000 SAPS.

Daraus lesen wir zunächst mal ab, dass Solaris/Oracle 2270 SAPS mehr aus gleicher 2-Sockel-Hardware herausholt (etwa 12%). Bei größeren Systemen steigt dieser Vorsprung auf 21%.

Der Windows-Benchmark von Sun kam – wie man an der recht hohen Zertifikatsnummer sehen kann – recht spät. Es war, so meine Kollegen aus dem Benchmarking, zunächst mal ein Zertifizierungsbenchmark.

Nur ein Zertifizierungs-Benchmark? Das ausstattungsmäßige Pendant zur Sun Fire X4270 ist die HP DL380 G6. Und die hat auch einen Windows-Benchmark:

  • Zertifikat 2009004: HP ProLiant DL380 G6, 2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 48 GB main memory, Windows 2008 Server & MS SQL-Server 2008: 3.300 User, 18.030 SAPS.

Also hat die X4270 mehr Windows-Power, 700 SAPS mehr sind immerhin  3,9%. Schaut man sich die Windows-Benchmarks anderer Hersteller an, sieht es immer ähnlich aus. Cisco erreicht stolze  3.200 User (Glückwunsch zum ersten Benchmark-Ergebnis!), Hitachi bietet 80 weniger, … lassen wir das.

Gut, HP kann auch mehr als 3300 SD-User. Sie haben ihr 2-Sockel-Blade antreten lassen:

  • Zertifikat 2009031: HP ProLiant BL460c G6, 2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 48 GB main memory,Windows 2008 Server & MS SQL-Server 2008: 3.415 User, 18.670 SAPS

Tja, immer noch einen User Vorsprung für Sun. Lustig, Sun hat den schnellsten Windows-2-Wege-2tier-SD-Benchmark des Jahres 2009!

Was kann man nun aus diesen Benchmarks ableiten?

  1. Der Solaris-Vorsprung beweist sich auf ein Neues. Bei identischer Hardware bringt Solaris ein mehr an Leistung, das beachtlich ist.
  2. Will man unbedingt Windows nutzen, bietet der Sun-Server die meiste Performance (wenn auch nur sehr knapp).

Ein paar weitere Erkenntnisse lassen sich aus den Ergebnissen auch ableiten:

  • HP und Sun beherrschen aktuell den Benchmark. Im Jahr 2009 wurden 41 Resultate im 2tier SD-Benchmark  veröffentlicht, die meisten davon waren von HP (17) und Sun (9). Es ist davon auszugehen, dass diese beiden Benchmark-Teams den Benchmark gut beherrschen, was gerade der hauchdünne Vorsprung von Sun im Windows-Benchmark beweist.
  • Dennoch sind die anderen Nehalem-Benchmarks, insbesondere die unter 3300 SD-Usern liegen, kein Beweis für die Unfähigkeit der anderen Firmen. Sie beweisen nur, dass diese Firmen anscheinend weniger Arbeit in ihre SAP-Benchmarks stecken wollen. Sie fahren “Zertifizierungs-Benchmarks”, und gut ist.
  • HP und Sun beweisen Engagement in ihren Benchmarks, HP beschränkt sich aber auf x86-Hardware (Intel und AMD) und sie beweisen nur mit Windows und Linux ihre Leistung. Auf einen Itanium-Benchmark wartet man vergebens. Okay, die aktuelle Itanium-Hardware hat schon ein paar Jahre auf dem Buckel und Gerüchten zufolge hat der neue Itanium “Tukwila” mittlerweile den Codenamen “Godot” bekommen.
  • IBM – sorry Jungs – gibt ein schwaches Bild ab. Keinerlei x86-Benchmarks, weder Linux noch Windows noch Solaris. Ein einzelner SD-Benchmark, bei dem Power 6 schlechter abschneidet als der Xeon 5570. Statt dessen nur ein paar BI-Benchmarks, bei denen man sich nur mit sich selbst messen muss.

Tags: , ,

Schlanke Virtualisierung

Jan September 14th, 2009

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.

Tags: , , ,

Der neue SAP-SD-2tier-Benchmark

Jan März 31st, 2009

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

Tags: , , ,

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

Jan März 30th, 2009

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.

Tags: , , ,

  • Links