Hello Noah,
>> Thread create time seems to be expensive as well, maybe up 0.1
>> seconds under some conditions (?). Under --rate, this create delay
>> means that throttling is laging behind schedule by about that time,
>> so all the first transactions are trying to catch up.
>
> threadRun() already initializes throttle_trigger with a fresh timestamp.
> Please detail how the problem remains despite that.
Indeed, I did this kludge because I could not rely on the "before fork"
start time as it was (possibly) creating a "rush" at the beginning of the
run under --rate.
The version I submitted takes the start time after the thread is created,
and use it directly for throttling, so the start time is taken once per
thread and used instead of retaking it because the first one cannot be
relied on.
> [...]
Fine detailed analysis!
> Opinions, other ideas?
I do not think that there is a clean and simple way to take the start/stop
period into account when computing global performances of a run. The TPC-C
benchmark tells to ignore the warmup/closure period, whatever they are,
and only perform measures within the steady state. However the full graph
must be provided when the bench is provided.
About better measures: If I could rely on having threads, I would simply
synchronise the threads at the beginning so that they actually start after
they are all created, and one thread would decide when to stop and set a
shared volatile variable to stop all transactions more or less at once. In
this case, the thread start time would be taken just after the
synchronization, and maybe only by thread 0 would be enough.
Note that this is pretty standard stuff with threads, ISTM that it would
solve most of the issues, *but* this is not possible with the "thread fork
emulation" implemented by pgbench, which really means no threads at all.
A possible compromise would be to do just that when actual threads are
used, and let it more or less as it is when fork emulation is on...
--
Fabien.
