Timers (Heap vs. RocksDB)

Question

as I'm using RocksDB as state backend to my Flink job and I'm configuring parameters of this state backend, I've read in this page of Flink that I have two options to keep my timers (rocksDB or heap), and I have read the explanation but still missing what means this part of it:

"However, maintaining timers in RocksDB can have a certain cost, which is why Flink provides the option to store timers on the JVM heap instead, even when RocksDB is used to store other states. Heap-based timers can have a better performance when there is a smaller number of timers."

1. what kind of cost is this that they mentioned here (latency)?
2. What means smaller number of timers (can be measured in somehow this number and what could be the maximal number of timers allowed in heap)?

Answer 1

Heap-based timers can be accessed with less latency. The benchmarks I've heard cited only a modest improvement (a 5-10% speedup). However, keeping your timers on the heap adds to the number of objects involved in garbage collection, so this can also harm overall performance (e.g., worst-case latency).

I think you would have to do your own benchmarking to be sure what's best in your situation, but I wouldn't expect any dramatic effect one way or the other.