Relation between pg_total_iterations and pg_duration

[johnyvincent]

Hello,

I am trying to evaluate an SSD drive with PostgreSQL using HammerDB. I have specified pg_total_iterations as 1000000. I have also set pg_duration as 2. From what I understand, hammerDB workloads will run for the duration specified by pg_duration, which is 2 minutes in my case. If so, what is the purpose of specifying the total_iterations?
Basically what I am trying to achieve is to get my test to run specific number of transactions per virtual user. I am also varying the total virtual user count in a for loop. For eg, I want 25 user to perform 1000000 transactions each before signing off. Then another set of 50 virtual users will sign in and perform the transactions and so on. But since the pg_duration parameter is set as 2 minutes, the test exits after 2 minutes.

As an experiment, I tried setting the test duration to 0 so as to check if the configured virtual users will perform the 1000000 operations and then exit. But I see that the test never ends in this case.

So how do I get the configured Virtual Users to perform the specified number of operations and then exit without considering the time?

Thanks

[sm-shaw]

There are a number of questions here.
I am trying to evaluate an SSD drive with PostgreSQL using HammerDB
With the default TPROC-C workload - see the cached vs scaled section here - most of the data will be cached in memory - so what you will mostly be testing is the write throughput to the WAL. In particular, the key dependency will be latency and therefore the synchronous commit setting will have the biggest impact. If you want to increase the I/O to the data area you should look at the advanced options of "use all warehouses" and "asynchronous scaling".
Basically what I am trying to achieve is to get my test to run specific number of transactions per virtual user.
This is what the asynchronous scaling option is for. This implements a workload closer to the TPC specification with keying and thinking time, in this case the maximum throughput is 1.28 NOPM per virtual user (if you look at the tpc-c specification) this is 1/10th of the 12.86 tpmC per warehouse (with 10 users per warehouse).
So if we look at an example of 1 virtual user with 1000 sessions we can see we are implementing something very close to this guidance.

and 2 virtual users gives us double this value

You will need middleware such as pg_bouncer to scale connections correctly, however this asynchronous scaling is the correct way to test with a fixed throughput that you then scale up and down with the number of virtual users.
Relation between pg_total_iterations and pg_duration
For a timed test if you want to measure the NOPM typically you want the number of iterations to be higher than the test time, so that the timing ends the test.
However we can set the total_iterations to a lower value as special case when we want a virtual user to log on and off multiple times, we then can set the iterations value in the virtual user settings to a value for the number of transactions to complete each time. This can be useful when you are testing for example a cluster or middleware load balancer and want to test sessions logging on and logging off mutliple times to check the distribution of where those connections are sent.
The example below shows 10 iterations of a test.

As we are not interested in timing the result we have used the test driver script, this however produces output, so if you want the same effect without output (note that all output is sent to the main thread so will impact performance when shown) you can either comment out the commands that print the output in the test script ("puts" command) (and use customscript for the CLI) or as a quick hack set rampup and duration to 0 - then the monitor VU will run up to the iterations setting and error each time, leaving the other virtual users to complete their iterations.

This gives you multiple options on configuring a workload for your needs, however for fixed throughput the asynchronous scaling is the best option here.

[johnyvincent]

Thanks Steve for the detailed explanation. The hack of setting ramp-up time and duration as 0 does what I exactly wanted.