Re: Adding a pgbench run to buildfarm
От | Bort, Paul |
---|---|
Тема | Re: Adding a pgbench run to buildfarm |
Дата | |
Msg-id | DB106B1B5B8F734B8FF3E155A3A556C202D4FD5E@clemail1.tmwsystems.com обсуждение исходный текст |
Ответ на | Re: Adding a pgbench run to buildfarm (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Adding a pgbench run to buildfarm
|
Список | pgsql-hackers |
Andrew Dunstan wrote: > > We are really not going to go in this direction. If you want ideal > performance tests then a heterogenous distributed collection of > autonomous systems like buildfarm is not what you want. > > You are going to have to live with the fatc that there will be > occasional, possibly even frequent, blips in the data due to other > activity on the machine. > > If you want tightly controlled or very heavy load testing this is the > wrong vehicle. > > You might think that what that leaves us is not worth having - the > consensus in Toronto seemed to be that it is worth having, > which is why > it is being pursued. > I wasn't at the conference, but the impression I'm under is that the point of this isn't to catch a change that causes a 1% slowdown; the point is to catch much larger problems, probably 20% slowdown or more. Given the concerns about running this on machines that don't have a lot of CPU and disk to spare, should it ship disabled? Andrew, what do you think of pgbench reports shipping separately? I have no idea how the server end is set up, so I don't know how much of a pain that would be. Regards, Paul Bort P.S. My current thought for settings is scaling factor 10, users 5, transactions 1000.
В списке pgsql-hackers по дате отправления: