On 08/27/2014 12:41 PM, Fabien COELHO wrote:
Hello Heikki,
I find the definition of the latency limit a bit strange. It's a limit on how
late a transaction can *start* compared to it's scheduled starting time, not
how long a query is allowed to last.
Yes. This is what can be done easily with pgbench under throttling. Note
that if transactions take long it is recorded (average, stddev...) so it
appears elsewhere.
How do figure out what it should be set to?
It is really just a simple tool to measure unresponsiveness under
throttling, which I'm testing and complaining about in another thread.
Ok, but wouldn't the definition I gave be just as useful for that
purpose, and more useful in general?
You didn't really answer my question: How do you figure out what to set
it to? With a latency limit on when the query should finish, as opposed
to how late it can start, it's a lot easier to give a number. For
example, your requirements might state that a user must always get a
response to a click on a web page in 200 ms, so you set the limit to 200 ms.
So I think a more useful model is that new queries arrive at a given
rate, and each query is expected to finish in X milliseconds from its
arrival time (i.e the time the query is scheduled to begin, not the time
it was sent to the server) or it's counted as failed. If a transaction
cannot even be started by that deadline, because the connection is still
busy with the previous query, it's counted as failed without even
sending it to the server. With that definition, it makes sense to
specify the latency limit even without --rate.
Yep. But that is not what I'm doing here. It would be interesting as well.
It would be another patch.
Why is your patch more interesting than what I described? I'm pretty
sure we don't need both.
In that case, it's simply a limit on how long each query's
execution is allowed to last until it's considered as failed. IOW, each
query's scheduled start time is when the previous query ends.
Not under --rate... that is the point of throttling!
Right, I got that. With "in that case", I meant when you're not throttling.
Under throttling,
the latency should really be computed wrt to the schedule start time and
not the actual start time which may be 10 seconds afterwards when things
are going bad... Also, there is the question of whether the "failed query"
is executed or not. Here I'm not executing them, in effect they were
aborted by the application. With your suggestion they would be executed
anyway but considered failed.
I was thinking that if a query is already late when the connection
becomes free to execute it, it would not be executed. It would be
skipped, just as in your patch.
So what you are suggesting is another (interesting) functionnality, that
could indeed be named "latency limit" (count slow above a threshold
queries), what I'm doing here is "lag limit" (scheduled query could not
start on time and are skipped, this is really specific to --rate).
Ok, but *why* are you doing a "lag limit", and not a "latency limit"?
Under what circumstances is the lag limit a more useful setting?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
