From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | Yeb Havinga <yebhavinga(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Testing Sandforce SSD |
Date: | 2010-07-26 18:34:39 |
Message-ID: | 4C4DD53F.4070901@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Matthew Wakeling wrote:
> Yeb also made the point - there are far too many points on that graph
> to really tell what the average latency is. It'd be instructive to
> have a few figures, like "only x% of requests took longer than y".
Average latency is the inverse of TPS. So if the result is, say, 1200
TPS, that means the average latency is 1 / (1200 transactions/second) =
0.83 milliseconds/transaction. The average TPS figure is normally on a
more useful scale as far as being able to compare them in ways that make
sense to people.
pgbench-tools derives average, worst-case, and 90th percentile figures
for latency from the logs. I have 37MB worth of graphs from a system
showing how all this typically works for regular hard drives I've been
given permission to publish; just need to find a place to host it at
internally and I'll make the whole stack available to the world. So far
Yeb's data is showing that a single SSD is competitive with a small
array on average, but with better worst-case behavior than I'm used to
seeing.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-07-26 18:40:43 | Re: Testing Sandforce SSD |
Previous Message | Greg Spiegelberg | 2010-07-26 16:26:45 | Re: Testing Sandforce SSD |