Re: usleep feature for pgbench

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: usleep feature for pgbench
Дата
Msg-id Pine.GSO.4.64.0707060323450.17749@westnet.com
обсуждение исходный текст
Ответ на Re: usleep feature for pgbench  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-hackers
On Thu, 5 Jul 2007, Jan Wieck wrote:

> Original pgbench reported 39, 37 and 33 TPS. Having my patch applied it 
> reported 40, 38 and 33 TPS. Inserting a "\usleep 1" after the update to 
> accounts of a default equivalent script changed those numbers to 40, 37 and 
> 33. I interpret that as "does not change observed performance".

Tell you what:  put your work into a patch, send it to the list, and I'll 
test that it doesn't degrade results for you.  If your pgbench results are 
in the <40 TPS range even with that low of a scale, you're not in a 
position to tell whether it has a negative performance impact.  That 
select statement you're fiddling with can turn into a bottleneck at high 
client loads, and from your description I can't tell if you've made that 
worse, but you'll never see it unless you're pushing, say,
>1000 TPS and >50 clients.  Also:  3 pgbench results at one client load
is quite a bit short of proving no impact on performance; I'll queue up 50 
or so, which is where I start to trust results from that unruly tool.

This is actually a feature I'd be kind of interested to have, because it 
would allow you to pass two (or more) script files to pgbench and adjust 
the transaction mix.  What happens when you do that right now is that 
inevitably all the clients get blocked at once on whatever the hardest to 
execute transaction is, and the results are kind of deceptive as a result.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tsearch2: language or encoding
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Bgwriter strategies