Investigate potential lock contention in DBImpl::WriteImpl when writing to the PartitionStore

[tillrohrmann]

While benchmarking Restate, I noticed that we spend a lot of time in rocksd::DBImpl::WriteImpl when trying to commit the PartitionStoreTransaction from the different partition processors. I suspect that this might be cause by lock contention. Unfortunately, the flamegraphs on MacOS don't give more insights.

The results of throughput/parallel with main 361e6a8 were:

throughput/parallel     time:   [397.84 ms 412.47 ms 426.13 ms]
                        thrpt:  [9.3868 Kelem/s 9.6976 Kelem/s 10.054 Kelem/s]

[tillrohrmann]

I've tried a simple experiment where every PartitionStore gets its own RocksDB instance to avoid contention completely. The results of the throughput/parallel benchmark are:

throughput/parallel     time:   [354.54 ms 359.25 ms 364.08 ms]
                        thrpt:  [10.986 Kelem/s 11.134 Kelem/s 11.282 Kelem/s]

and the flamegraph no longer shows time spent on awaiting the lock when writing to the PartitionStore (DBImpl::WriteImpl):