Re: pgbench throttling latency limit - Mailing list pgsql-hackers

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