Re: Opteron vs. Xeon "benchmark" - Mailing list pgsql-performance

From nicky
Subject Re: Opteron vs. Xeon "benchmark"
Date
Msg-id 4513A59E.3000807@valuecare.nl
Whole thread Raw
In response to Opteron vs. Xeon "benchmark"  (Hannes Dorbath <light@theendofthetunnel.de>)
Responses Re: Opteron vs. Xeon "benchmark"  (Vivek Khera <vivek@khera.org>)
List pgsql-performance
Hello Hannes,

The text above the pictures on page 13. Translated in my crappy english.

The confrontation between the Opteron and Woodcrest was inevitable in
this article, but who can add 1 and 1 should have known from the
previous two pages that it doesn't look that good for AMD . Under loads
of 25 till 100 simultaneous visitors, the Xeon performs 24% better with
MSQL 4.1.20, 30% better in MySQL 5.0.20a and 37% better in PostgreSQL
8.2-dev. In short, the Socket F Opteron doesn't stand a chance, although
the Woodcrest scales better and has such a high startpoint with one
core, there is no chance of beating it. We can imagine that the Opteron
with more memory and production hardware, would be a few % faster, but
the difference with the Woodcrest is that high that we have a hard time
believing that the complete picture would change that much.


Regards,
Nick

Hannes Dorbath wrote:
> A colleague pointed me to this site tomorrow:
>
> http://tweakers.net/reviews/642/13
>
> I can't read the language, so can't get a grip on what exactly the
> "benchmark" was about.
>
> Their diagrams show `Request per seconds'. What should that mean? How
> many connections PG accepted per second? So they measured the OS fork
> performance? Should that value be of any interrest? Anyone with heavy
> OLTP workload will use persistent connections or a connection pool in
> front.
>
> Do they mean TPS? That woulnd't make much sense in a CPU benchmark, as
> OLTP workload is typically limited by the disc subsystem.
>
> Can someone enlighten me what this site is about?
>
>

pgsql-performance by date:

Previous
From: Markus Schaber
Date:
Subject: Re: Large tables (was: RAID 0 not as fast as
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Large tables (was: RAID 0 not as fast as