The benchmark begins with spike as below (see the values in bold). It hinders our test use cases. Wondering if I can configure to stop this behaviour?
[root@aspike benchmarks]# ./run_benchmarks -h 127.0.0.1 -p 3000 -n test -k 10000000 -b 1 -o B:1400 -w RU,80 -g 1000 -T 50 -z 8
Benchmark: 127.0.0.1 3000, namespace: pcrf, set: testset, threads: 8, workload: READ_UPDATE
read: 80% (all bins: 100%, single bin: 0%), write: 20% (all bins: 100%, single bin: 0%)
keys: 10000000, start key: 0, transactions: 0, bins: 1, random values: false, throughput: 1000 tps
read policy:
socketTimeout: 50, totalTimeout: 50, maxRetries: 2, sleepBetweenRetries: 0
consistencyLevel: CONSISTENCY_ONE, replica: SEQUENCE, reportNotFound: false
write policy:
socketTimeout: 50, totalTimeout: 50, maxRetries: 2, sleepBetweenRetries: 500
commitLevel: COMMIT_ALL
Sync: connPoolsPerNode: 1
bin[0]: byte[1400]
debug: false
2017-06-28 17:45:35.516 INFO Thread main Add node BB9A689B63E16FA 127.0.0.1 3000
2017-06-28 17:45:35.535 INFO Thread main Add node BB9ACB2B93E16FA 10.0.0.9 3000
2017-06-28 17:45:36.593 write(tps=**1960** timeouts=0 errors=0) read(tps=**8129** timeouts=0 errors=0) total(tps=10089 timeouts=0 errors=0)
2017-06-28 17:45:37.593 write(tps=211 timeouts=0 errors=0) read(tps=797 timeouts=0 errors=0) total(tps=1008 timeouts=0 errors=0)
2017-06-28 17:45:38.593 write(tps=192 timeouts=0 errors=0) read(tps=822 timeouts=0 errors=0) total(tps=1014 timeouts=0 errors=0)
2017-06-28 17:45:39.594 write(tps=214 timeouts=0 errors=0) read(tps=802 timeouts=0 errors=0) total(tps=1016 timeouts=0 errors=0)
2017-06-28 17:45:40.594 write(tps=179 timeouts=0 errors=0) read(tps=832 timeouts=0 errors=0) total(tps=1011 timeouts=0 errors=0)
2017-06-28 17:45:41.595 write(tps=198 timeouts=0 errors=0) read(tps=816 timeouts=0 errors=0) total(tps=1014 timeouts=0 errors=0)