Re: [osdldbt-general] Ideas

[Jim C. N. <jn...@pe...>]

On Mon, Aug 29, 2005 at 03:00:32PM -0700, Mary Edie Meredith wrote:
> On Tue, 2005-08-23 at 18:46 -0500, Jim C. Nasby wrote:
> > Now that I've been using dbt2 a bit I've got some enhancement ideas I'd
> > like to run past everyone...
> > 
> > It would be very beneficial if there was an easy way to queue up
> > different performance runs. Writing a shell script to run a bunch of
> > parameters gets tedious after a while. To start with it would be good
> > just to be able to load up a bunch of different run_workload parameters
> > you'd like to try, but eventually it would be very useful to be able to
> > swap in different config files/settings or even code patches.
> > 
> > Improving on the current scheme for storing results would also be
> > welcome. The patch I submitted that creates a log.html helps a bit, but
> > there's still a lot of room for improvement. Being a database guy, an
> > obvious solution that comes to mind is storing some (or even all) of the
> > result data in a database (though prefferably not one that's on the test
> > machine).
> 
> I would eagerly support doing this as an option i.e. output to flat
> file, database, or both.  I can't imagine the sar output in a database,
> nor the various logs that we mostly use for debugging, so I'm guessing
> you mean to store the metrics mostly?   This would be nice because we
> can then get the best of both worlds (SQL versus command-line).

Definately the metrics, but I see no reason not to store the other stuff
as well.

> Also, you mention not storing the resulting data on the test machine.
> Many times we run the driver on the test machine.  Not ideal, but
> keeping it to one tier makes set-up easier.  Perhaps you can store the
> results at the end of the test into the database.  Most of the metrics
> are computed after the run anyway...

ISTM that it shouldn't be that hard to set things up so that the test
script connects to a remote database to test. You should even be able to
do the monitoring stuff remotely with ease, if you have ssh setup to use
agent authentication. It could even use a remote database to store all
the results.

Of course that's all stuff for later. Step one is just to get stuff
going into a database.

> > Likewise, having a web interface to things would be a great improvement.
> Again, hopefully an option, not a replacement? 

Yes, absolutely. We should always have the 'simple option'.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jn...@pe...
Pervasive Software        http://pervasive.com        512-569-9461