Try out making a read cache for poolmanager pool modules (backport #8128) #8153
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Try out making a read cache to avoid extra unmarshals.
For the state machine im pretty confident it will work, it may break the errors for some weird queries to old heights (since it will share this cache, and should really return a miss). But this will only be an edge case for new pools.
We should def test it in prod, but I think this should eliminate this 4.73 out of 1100 seconds of sync time:
More importantly i think this will be helpful as a stepping stone to figuring out a more general, re-usable design pattern for us. We could just cache the proto unmarshals, but we would then still pay the key formatting cost. We could cache both key formatting and proto unmarshal in this case.
More general case, we likely do need to cache the two steps differently and use LRU's.
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Chores
This is an automatic backport of pull request #8128 done by [Mergify](https://mergify.com).