BUG-650: use SameThreadExecutor for commits
Profiling has shown that the cost of performing a forced context switch
in execution path of the data store leads to ~2x performance
degradation (23600 vs. 40000 ops/s), with average of 20 runs:
InMemoryDataStoreWithExecutorServiceBenchmark: total stddev
write100KSingleNodeWithOneInnerItemInCommitPerWriteBenchmark 4227.384 ms 61.172
write100KSingleNodeWithOneInnerItemInOneCommitBenchmark 286.954 ms 14.350
write10KSingleNodeWithTenInnerItemsInCommitPerWriteBenchmark 364.004 ms 12.687
write10KSingleNodeWithTenInnerItemsInOneCommitBenchmark 17.936 ms 0.883
write50KSingleNodeWithTwoInnerItemsInCommitPerWriteBenchmark 1979.140 ms 56.529
write50KSingleNodeWithTwoInnerItemsInOneCommitBenchmark 136.749 ms 6.402
InMemoryDataStoreWithSameThreadedExecutorBenchmark: total stddev
write100KSingleNodeWithOneInnerItemInCommitPerWriteBenchmark 2475.137 ms 220.396
write100KSingleNodeWithOneInnerItemInOneCommitBenchmark 267.298 ms 7.063
write10KSingleNodeWithTenInnerItemsInCommitPerWriteBenchmark 180.537 ms 1.337
write10KSingleNodeWithTenInnerItemsInOneCommitBenchmark 19.582 ms 0.200
write50KSingleNodeWithTwoInnerItemsInCommitPerWriteBenchmark 1127.771 ms 87.438
write50KSingleNodeWithTwoInnerItemsInOneCommitBenchmark 134.401 ms 2.110
The analysis is that the underlying component (yang-data-impl's
DataTree) can process operations at a rate exceeding 30K ops/s,
obviously depending on size, which means a transaction is completed
every ~35 microseconds. When we factor in the fact that there is at most
one transaction issued at a particular moment (due to ordering/conflict
resolution), the ill effects of forced context switches become very much
pronounced.
This patch switches the executor service to SameThreadExecutor, which
foregoes queueing and executes the task on the submitting thread (which
is the datastore coordinator thread, not some user thread).
The option to switch the executor service is left intact, but may be
removed in future pending further benchmarks.
Change-Id: Ic1c4c0b1b80aa77c2d85810736bdc370a465eee8
Signed-off-by: Robert Varga <rovarga@cisco.com>