Message-ID: <4C4DD53F.4070901@2ndquadrant.com>
Date: Mon, 26 Jul 2010 14:34:39 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Matthew Wakeling <matthew@flymine.org>
CC: Yeb Havinga <yebhavinga@gmail.com>, pgsql-performance@postgresql.org
Subject: Re: Testing Sandforce SSD
References: <4C4A9452.9070100@gmail.com> <4C4B1F84.5030306@2ndquadrant.com>
	<4C4C83DF.3010703@gmail.com> <4C4C8CCC.7080406@gmail.com>
	<alpine.DEB.2.00.1007261045470.20471@aragorn.flymine.org>
	<4C4DA982.5090308@2ndquadrant.com>
	<alpine.DEB.2.00.1007261632380.20471@aragorn.flymine.org>
In-Reply-To: <alpine.DEB.2.00.1007261632380.20471@aragorn.flymine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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@2ndQuadrant.com   www.2ndQuadrant.us