PeopleSoft North American P...

Ich hatte das schon an anderer Stelle erklaert:

- Die 40 SSD wurden aus kapazitaetsgruenden benoetigt. Die Datenbanken haetten gemirrored knapp nicht auf 20 gepasst.
- die HP Konfiguration sind nicht nur blosse platten, das ist eine EVA8100 (also ein wenig groesser, naechst groessers als das ist eine XP)... statt 3 Hoeheneinheiten sind das bei HP fast ein halbes Rack.
- Bisher waren 8 Streams eigentlich ueblich, mit 16 Streams haette man auch bei der Sun konfiguration ganz andere werte erreicht. Da allerdings vorher alls Ergebnisse 8er waren, hat sich Sun hier auch fuer 8 Streams entschieden.

Naja ... mithalten ... wohl nicht guck dir mal die Auslastungswerte an ... die M4000 idled fast ... naja 25% auslastung, wo die andere Itaniummaschine bei etwa 80-90% liegt. Würde man die M4000 von der Kette lassen, würden da ganz andere werte bei rum kommen ... aber dann wäre das nicht vergleichbar gewesen zu den zu jenem Zeitpunkt herausgegebenen anderen Benchmarkergebnissen. Zudem mögen SSD hohe Threadzahlen.

Was die 8100 angeht: Du darfst die erheblichen Mengen Cache in den Controllern nicht vergessen.

1. Klar ist der vergleich nicht fair: Peoplesoft Large Modell mit 8 Threads vermag die M4000/F5100 nicht mal ansatzweise auszulasten Aber scheint so eine Standardparametrisierung zu sein. Irgendwas sagt mir, das man den gleichen Test auch mit einer M3000 haette machen koennen, ohne allzuviel zu verlieren. Die SSD waren nicht in MaxPerf-Konig , yadda, yadda , yadda ...

2. Klar kann man die XP nicht vergleichen, ist ja auch nicht von HP

3. Klar ist das alles nicht so vergleichbar, aber wie saehe denn eine SSD loesung aus ? Da wuerden auch nur STECs reingeschraubt werden. Eine solche Lösung waere auf jeden Fall groesser, wenn man einfach SSD reinschrauben wuerde. Und auch da waere der Controller schnell saturiert.

4. Klar ist die 8100 nicht das neuste System, aber warum hat HP dann nicht ein neueres System gemacht. Der vergleichbare Benchmark mit 16 Threads ist von Anfang Oktober diesen Jahres ....

5. Objektiv ist der Vergleich schon: Zwei Umgebungen werden im gleichen Benchmark gegeneinander laufen gelassen. Es kommen zwei Werte raus. Es sind sogar zwei Benchmarks, die zum selben Zeitraum gemacht worden sind Man mag ueber die Fairness streiten, aber HP hat sich entschieden, die Benchmarks mit der 8100 zu machen, nicht Sun

6. Selbst 2 GB sind nicht unerheblich. Dazu scheint diese Konfig auch noch sehr short-stroked zu sein (Nutzdaten zu Gesamtkapazität ist sehr sagen wir mal grosszugig bemessen) ...

giggle Also die Geschichte, das HP mehr als den Vendorstring aendert, habe ich auch schon gehoert. Aber die Geschichte, das sie jetzt schon dabei mitentwickeln is mir neu Sagen wirs mal so ... ich sag da mal nichts zu

Ja, ich weiss das HP das gerne sagt

They aren't better ... the newer benchmark isn't comparable to the benchmark ... the Sun result used 8 threads, the HP's 16 ... the comparable benchmark yielded a 33% better result for the Sun hardware ... 25% load on Sun hardware, almost 90% at HP, short stroked hard disks at HP ... it goes that way ... only the cursory observer doesn't see this differences ...

And sorry: The revised benchmark from HP is from last month ... why they didn't used it ?

Your severe lack of clue gets really astounding:

0. 8 versus 16 streams. 25% versus over 80% utilisation. Read the document. JBOD vs. enterprise array. And the point still holds true: With the same number of streams the sun solution is 33% faster and nowhere near it's limit.
1. The harddisks were used due to the fact, that the F5100 and many other flash devices are optimized for 4k blocks.
2. This benchmark was limited by the 8 stream condition, not by the hardware. Neither the harddisks nor the flash nor the system were near the limit of the respective systems. But as the size of the model is defined by oracle and the 8 streams were defined by the other benchmarks results to keep them comparable.
3. The amount of storage used by this benchmark was almost 500 GB. The database size refers AFAIK to the data alone (the amount you get when you dump it to a file) ... not all the files surrounding the database. By the way: You could now this earlier ... the database size is always 200GB

I really knew that you would comment here on this article, and that you would make this point ... but at the end it just shows that you are missing important points and don't really understand the matter ...