Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
12475: Introduce cache for process versions r=megglos a=Zelldon ## Description When executing a process instance we often have to get the process model and related version to it. When running a cluster for a while (creating a lot of state etc.) the process version will eventually be migrated to a low level of RocksDB (potentially L3), because most of the time process models are not deployed that often. In other words, if a key is not updated it will be moved to a lower level by RocksDB. Accessing lower levels of RocksDB is slower than accessing higher levels or mem tables. You might ask why is it slow, even if we repeatedly access via RocksDB, why is it not in the cache? There are multiple reasons for it. 1. We only have caches for L0, and L1 configured (not for lower levels) 2. We have limited the cache sizes to a certain amount which might cause continuous eviction In order to avoid running into issues with cold data, which is mostly static data, we can introduce our own caches, to work around this. This allows us to avoid unnecessary RocksDB access, unnecessary io, etc. **This PR does the following:** * Refactors the NextValueManager, including renaming as its only purpose is to be used for ProcessVersions * Introduce a new cache for the version of each process, in order to avoid access to cold data. **Performance:** We run again a JMH benchmark with the changes and can see that the performance _slightly_ increased (potentially 8%), not significant but it will likely come into play with other changes later. [See more details here ](#12241 (comment)) <!-- Please explain the changes you made here. --> ## Related issues <!-- Which issues are closed by this PR or are related --> closes #12034 Co-authored-by: Christopher Zell <zelldon91@googlemail.com>
- Loading branch information