Database benchmarking system:
=============================

This tool can be used to benchmark any JDBC compliant data source.
The basic idea is to run an arbitrary set of SQL scripts on a single
server. The benchmarking tool will log the duration of every set
in a file which can be analyzed after the benchmark.


Compiling:
==========

Simply run "ant" - the build script will generate a jar file in our
/tmp directory (see output when running ant).


Starting:
=========

replication_benchmark.jar supports various parameters:
	-c: number of concurrent users
	-u: JDBC url
	-q: directory containing a set of SQL scrips
	-r: directory containing the results
	-n: run those input scripts "n" times
	-t: tag this run using a name (e.g.: "pgsql_with_fsync_")


Evaluation:
===========

To evaluate the results import the scripts generated in the directory defined by
"-r" into a database. Run any kind of analysis on this data to see what is faster.


The result set:
===============

As mentioned before results can be found in the desired output directory.
The fileformat is as follows.
Example:

INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '02.sql', '2', '0', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '02.sql', '1', '1', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '01.sql', '4', '0', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '02.sql', '0', '1', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '02.sql', '3', '0', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '01.sql', '2', '0', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '01.sql', '1', '1', '5'); 
INSERT INTO t_benchmark (tstamp, file, threadid, diff, active) VALUES (now(), '02.sql', '4', '0', '5'); 

The resultset has 5 columns:
	tstamp: 	When did we execute the query.
			You can use this to see what came after the ofter.
	file:		Which SQL script did we run?
	threadid:	Which thread number did that?
	diff:		Time needed in milliseconds.
	active:		How many threads where active when running the script.

The "active" flag is more or less essential. Please consider only records
where "active" = "-n" because otherwise you will get data. When "active" is lower
than "-n" the script tends to be faster because there are not enough other
backends looking for database power.


About checkpoints:
==================

Make sure that the tests run for a REASONABLE amount of time.
Database CHECKPOINTS can influence the behaviour of the database significantly.



------------------------------------
Vienna, January 3rd 2005.
Cybertec Geschwinde & Schoenig GmbH.
