From: | Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance testing framework.. |
Date: | 2009-10-08 00:39:43 |
Message-ID: | 4ACD34CF.8030706@amd.co.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith wrote:
> On Wed, 7 Oct 2009, Michael Renner wrote:
>
>> I haven't thought about result aggregation & rendering/UI part of the
>> whole thing so far, so if anyone has some ideas in that direction
>> they'd be very much appreciated when the time has come.
>
> What I did in pgbench-tools (now available at http://git.postgresql.org/
Thanks, I'll look into it! I think the nicest solution would be
something in the liking of Sun's Analytics [1] framework, especially
when you've got large amounts of historic data to correlate. But this
is probably a completely different beast to implement, though nice
Javascript rendering libraries become commonplace these days. We'll see...
> I'm not aware of anyone working on the job management side of the
> "performance farm" yet, so I don't think you duplicated anybody else's
> work.
Good to hear :)
> things, but basically one test at a time. The specific piece I've been
> working on lately is spawning off system monitoring daemons to collect
> information during the test, I think I'm on my 3rd generation of trying
> to get a solution I'm happy with to that problem.
Ahh, that'd be also nice to have to see how ressource consumption
differs between different runs & branches. This is probably highly
platform dependent though...
Michael
[1] http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics-overview/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-08 01:01:52 | Re: Concurrency testing |
Previous Message | David E. Wheeler | 2009-10-08 00:33:17 | Re: Concurrency testing |