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

2 Kommentare

  1. Welche Aussagekraft soll der Benchmark eigentlich haben? Vom verwendeten Storage ist nichts zu lesen, oder bin blind?
    Interessant wäre es außerdem erst wenn die Server-Hersteller den Benchmark auf selber Hardware in unterschiedlichen Konfigurationen durchführen würden, also unterschiedliche OS- und DB-Kombinationen.
    P.S.
    Die Performanceauswirkungen von Unicode sollte eigentlich jeder DBA oder SAP-Admin wissen. Die SAP gibt hierzu zahlreiche Zahlen bzgl. CPU-, RAM- und HDD-Mehrverbrauch heraus, der abhängig von der verwendeten DB ist:
    CPU: +10-30%
    RAM: +40-50%
    DB: UTF-8 +10%, UTF-16 +30-60%
    LAN: ~0%

  2. Hallo Otmanix,
    Storage hat einen minimalen Einfluss auf das Verhalten des SD-Benchmarks. Er ist zwar nicht „I/O-frei“, aber sind der Einfluss von Storage und verwendeter Datenbank sind recht gering. Ein Kollege von mir hat in unserem saponsun-Blog darüber gebloggt: http://blogs.sun.com/saponsun

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert