Re: Performance testing framework..

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/

In response to

Browse pgsql-hackers by date

  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