HammerDB custom TCL script strategy

[neocastro]

Hi there,

I'm trying to figure out how much of an impact the usage of bitemporal tables would have an application I'm working on. The options are MariaDB (system + application versioning), Postgres (vanilla, no bitemporality) and Postgres + some user-defined procedures from this repo.

Each one of this options have slightly different table structures and usage, while all DBs have been configured and tables created, I'm still a bit unsure about how to structure the TCL scripts. I plan to test on different # of virtual users and with different # of workloads (ex: 100k, 1M and 10M insertions/updates).

Am I able to have a single .sql script for each of the DBs and use HammerDB to split the statements between different virtual users, or should I have one script per virtual user with all the statements, and then in the TCL script load the corresponding .sql file based on the virtual user number? (E.g. virtual user 1 for mariadb will load the file "mariadb_vu_1.sql")

[sm-shaw]

I'm not entirely clear on the question. However there are a couple of features already in HammerDB that allows different virtual users to do different things:
Firstly, when you want one instance of HammerDB to make multiple connections (ie a connect pool) and run different stored procedures. Typically, this is used for clusters e.g. read/write and read only but can be set for a single instance as well.
https://www.hammerdb.com/blog/uncategorized/hammerdb-v4-0-new-features-pt4-connect-pooling-for-clusters/
https://www.hammerdb.com/docs/ch04s07.html#d0e2362
Secondly we have the primary/replica feature https://www.hammerdb.com/docs/ch08.html where you connect 1 or more replicas to a primary, you can distribute the primary script but then modify the scripts on the different replicas so again the different instances of HammerDB now are doing different things.
Also if you want to customise the scripts, and you look in the timed script as an example you can see there is a switch statement based on $myposition which is the virtual user id - by default virtual user 1 does the monitoring, so you can add additional sections if you wish to change the behaviour per VU eg in the following VU2 will just print a message and then finish successfully.

switch $myposition {
    1 { 
...
    }
   2 {
puts "Now Virtual User just prints a message"
    }
    default {
...
   }