The two main benchmarks we are currently working on measure throughput and latency during the benchmark to identify trends over time and to identify "spikes" in otherwise good runs.

We don't want to add system calls around every operation in wtperf, so instead we should have a measuring thread that wakes frequently (e.g., 100-1000 times per second), updates a global time variable (using gettimeofday) and sweeps the running threads.

For threads that have completed work since the last sweep, assume the per-operation latency is elapsed time / number of operations. In other words, if they are fast enough, just assume the latencies are all equal.

For a thread that got no work done, and has no timestamp set, record the current timestamp. If we see a thread with work done and the timestamp set, record one latency of the current timestamp minus the set timestamp, then clear the timestamp. Also record the "fast" latencies as above for the additional operations that completed in this round.

Use the same approach as LinkBench to capturing these latencies: divide them into buckets as in https://github.com/facebook/linkbench/blob/master/src/main/java/com/facebook/LinkBench/stats/LatencyStats.java

> The division into buckets is based on typical latencies for database operations: most are in the range of 0.1ms to 100ms. We have 0.1ms-granularity buckets up to 1ms, then 1ms-granularity from 1-100ms, then 100ms-granularity, and then 1s-granularity.

Have the stat_worker thread in wtperf output the throughput, mean, 95%, 99% and maximum latencies for each operation/thread type, rather than just the number of operations.