Re: [PATCH] add --throttle option to pgbench
От | Fabien COELHO |
---|---|
Тема | Re: [PATCH] add --throttle option to pgbench |
Дата | |
Msg-id | alpine.DEB.2.02.1304291945540.7344@localhost6.localdomain6 обсуждение исходный текст |
Ответ на | Re: [PATCH] add --throttle option to pgbench (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: [PATCH] add --throttle option to pgbench
|
Список | pgsql-hackers |
Hello Jeff, > While I don't understand the part about his laptop battery, I think that > there is a good use case for this. If you are looking at latency > distributions or spikes, you probably want to see what they are like with a > load which is like the one you expect having, not the load which is the > highest possible. Although for this use case you would almost surely be > using custom transaction files, not default ones, so I think you could just > use \sleep. However, I don't know if there is an easy way to dynamically > adjust the sleep value by subtracting off the overhead time and randomizing > it a bit, like is done here. Indeed, my thoughts:-) Having regularly (\sleep n) or uniformly distributed (\sleep :random_value) is not very realistic, and I would have to do some measures to find the right value for a target load. > It does seem to me that we should Poissonize the throttle time, then > subtract the average overhead, rather than Poissonizing the difference. I actually thought about doing it the way you suggested, because it was "right". However I did not do it, because if the Poisson gives, possibly quite frequently, a time below the transaction time, one ends up with an artificial sequence of stuck transactions, as a client cannot start the second transaction while the previous one is not finished, and this does not seem realistic. To really do that more cleanly, it would require distributing the events between clients, so having some kind of coordination between clients, which would really be another test application. Having an approximation of that seemed good enough for my purpose. -- Fabien.
В списке pgsql-hackers по дате отправления: