Re: analyzing, visualizing, understanding and rating I/O latency

Hum. I have a customer now in which average write times are over .030
seconds and read times are over .015. Pretty slow when compared to other
customers. But guess what? Nobody complains, ever. My thinking is IO is
slow = "when customer is not happy with response time" and "response time >
25% of total transaction/batch job time" and "read times > .015 and write
times > .030" and "weight more heavily if the job/transaction generates a
lot of writes".
Avg latency if prob fine, assuming this is not a first person shooter in
which a single long latency event could have catastrophic consequences for
a single user. So depends.

If you are just dealing with a "normal" system then what you want to look
at is events "way outside" the range of normal, so for example, a SQL which
normally runs in .1 seconds which all of a sudden takes 20 seconds. Now
that is an issue and you want to know why it went from .1 seconds to 20
seconds. If you are running a good SQL monitor you will get reports about
events like this. Ideally you will even be able to confirm SQL X
corresponds to business transaction Y and this is important/unimportance
because...another thing to monitor for would be a SQL which normally runs
in .1 seconds which all of a sudden runs in 2 seconds...(and a bunch of
other SQL's do the same thing all at the same time) what caused that?
That is something you should be monitoring for...especially if your host is
"in the cloud" so to speak.

On Mon, Jul 30, 2012 at 1:47 PM, kyle Hailey <kylelf@xxxxxxxxx> wrote:

> Two questions I'm interested in answering or getting opinions on are:


Other related posts: