Hello Tomas,
But I do think it's a very useful tool when it comes to measuring the
consistency of behavior over time, assuming you're asking questions
about the intervals and not the original transactions.
For a throttled run, I think it is better to check whether or not the
system could handle the load "as expected", i.e. with reasonnable latency,
so somehow I'm interested in the "original transactions" as scheduled by
the client, and whether they were processed efficiently, but then it must
be aggregated by interval to get some statistics.
For example, had there been intervals with vastly different transaction
rates, we'd see that on the tps charts (i.e. the chart would be much more
gradual or wobbly, just like the "unpatched" one). Or if there were intervals
with much higher variance of latencies, we'd see that on the STDDEV chart.
On HDDs what happens is that transactions are "blocked/freezed", the tps
is very low, the latency very high, but then with few tx (even 1 or 0 at
time) and all latencies very bad but nevertheless close one to the other,
in a bad way, the resulting stddev may be quite small anyway.
I'll consider repeating the benchmark and logging some reasonable sample of
transactions
Beware that this measure is skewed, because on HDDs when the system is
stuck, it is stuck on very few transactions which are waiting, but they
would seldom show on statistics are there are very few of them. That is
why I'm interested in those that could not make it, hence my interest in
--latency-limit option which just say that.
So I don't think this would make any measurable difference in practice.
I think that it may show that 25% of the time the system could not
match the target tps, even if it can handle much more on average, so
the tps achieved when discarding late transactions would be under
4000 tps.
You mean the 'throttled-tps' chart?
Yes.
Yes, that one shows that without the patches, there's a lot of intervals
where the tps was much lower - presumably due to a lot of slow
transactions.
Yep. That is what is measured with the latency limit option, by counting
the dropped transactions that where not processed in a timely maner.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
