[RelayMiner] Implement relayminer query caching #1050
Conversation
|
The image is going to be pushed after the next commit. You can use If you also want to run E2E tests, please add |
There was a problem hiding this comment.
@red-0ne I did a first partial review but have a lot of comments & questions.
Here's a high-level summary but PTAL at the actual comments as well:
- Need to understand if/how this can build on top of [Off-chain] feat: in-memory query cache(s) #994 w/ @bryanchriswhite
- See a few comments (logs + comments) that need to be addressed in multiple places
- I’m a bit concerned (and don’t understand) how we’re not using “height” to retrieve things from the cache, especially when values are always changing
- When does the cache ever get cleared?
- Light on tests
- I’d be interested to see numbers of performance improvement
| @@ -49,11 +53,19 @@ func NewSharedQuerier(deps depinject.Config) (client.SharedQueryClient, error) { | |||
| // Once `ModuleParamsClient` is implemented, use its replay observable's `#Last()` method | |||
| // to get the most recently (asynchronously) observed (and cached) value. | |||
| func (sq *sharedQuerier) GetParams(ctx context.Context) (*sharedtypes.Params, error) { | |||
| // Get the params from the cache if they exist. | |||
| if params, found := sq.paramsCache.Get(); found { | |||
There was a problem hiding this comment.
I'm concerned (and don't fully understand) the lack of a "height" param when retrieving things from the cache.
There was a problem hiding this comment.
This cache implementation does not add any new functionality besides caching whatever has been queried.
It does not alter the RelayMiners current behavior
RelayMinercold start- React to
Params change
For those reasons, it does not leverage historical data that justifies the usage of height for cache querying.
There was a problem hiding this comment.
My understanding is that the cache implementations here are NOT historical; i.e. ONLY the most recently observed value is cached for each ParamsCache instance (or key, in the case of KeyValueCache).
While #994 does include historical caching as well (via the HistoricalQueryCache interface, that's an additional and distinct feature.
This shouldn't be necessary here because we're clearing the cache on every new block. The end result being, somewhat sub-optimal, but significant caching. This reformulates the number off-chain queries from being a function of API usage, to no more than one per block, per cache.
|
|
||
| // WithNewBlockCacheClearing is a cache option that clears the cache every time | ||
| // a new block is observed. | ||
| func WithNewBlockCacheClearing[C Cache](ctx context.Context, deps depinject.Config, cache C) error { |
| } | ||
|
|
||
| // KeyValueCache is an interface for a simple in-memory key-value cache implementation. | ||
| type KeyValueCache[V any] interface { |
There was a problem hiding this comment.
pkg/client/query/sessionquerier.go
Outdated
| clientConn grpc.ClientConn | ||
| sessionQuerier sessiontypes.QueryClient | ||
| sharedQueryClient client.SharedQueryClient | ||
| sessionsCache KeyValueCache[*sessiontypes.Session] |
| @@ -49,11 +53,19 @@ func NewSharedQuerier(deps depinject.Config) (client.SharedQueryClient, error) { | |||
| // Once `ModuleParamsClient` is implemented, use its replay observable's `#Last()` method | |||
| // to get the most recently (asynchronously) observed (and cached) value. | |||
| func (sq *sharedQuerier) GetParams(ctx context.Context) (*sharedtypes.Params, error) { | |||
| // Get the params from the cache if they exist. | |||
| if params, found := sq.paramsCache.Get(); found { | |||
There was a problem hiding this comment.
My understanding is that the cache implementations here are NOT historical; i.e. ONLY the most recently observed value is cached for each ParamsCache instance (or key, in the case of KeyValueCache).
While #994 does include historical caching as well (via the HistoricalQueryCache interface, that's an additional and distinct feature.
This shouldn't be necessary here because we're clearing the cache on every new block. The end result being, somewhat sub-optimal, but significant caching. This reformulates the number off-chain queries from being a function of API usage, to no more than one per block, per cache.
Summary
Implements caching layer for query clients to reduce network calls and improve performance
Primary Changes:
KeyValueCacheandParamsCacheinterfaces with thread-safe implementationsAccount,Application,Bank,Service, etc.)WithNewBlockCacheClearingoptionSecondary Changes:
sync.Muteximplementation inaccQuerierwith new cache interfaceIssue
The RelayMiner RPC queries are not cached, which puts excessive load on the configured full node, degrading the performance of both off-chain and on-chain components.
Type of change
Select one or more from the following:
consensus-breakinglabel if so. See [Infra] Automatically add theconsensus-breakinglabel #791 for detailsSanity Checklist
assignees,reviewers,labels,project,iterationandmilestonemake docusaurus_startmake go_develop_and_testandmake test_e2edevnet-test-e2elabel to run E2E tests in CI