When using the run_ops option to control the length of a wtperf run, wtperf should report accurate performance numbers (i.e., ops/sec) at the end of the run.

The run_ops option to wtperf specifies the number of operations that a run of wtperf should perform. When using this option, wtperf doesn't track elapsed runtime, and therefore does not report useful performance numbers at the end of the run.

For example, the following simple wtperf command file uses run_ops to perform 10 million inserts. 

table_config="type=file"
run_ops=10000000
threads=((count=10,inserts=1))

It takes about 20 seconds to execute on my virtual workstation.

The end-of-run statistics, from the test.stat file, say:

Executed 10544912 insert operations (100%) 10544912 ops/sec
Executed 0 modify operations (0%) 0 ops/sec
Executed 0 read operations (0%) 0 ops/sec
Executed 0 truncate operations (0%) 0 ops/sec
Executed 0 update operations (0%) 0 ops/sec
Executed 0 backup operations
Executed 0 checkpoint operations
Executed 0 flush_tier operations
Executed 0 scan operations
Run completed: 10000000 operations

It turns out that if we use the run_ops command rather than run_time to control the length of the test, we always report that all of the operations happened in one second.

Instead we should read the clock at the beginning and end of the run and use the elapsed time to report meaningful performance statistics.