QueryCache: Shared query cache for all request going through runRequest

[torkelo]

It would be nice if Grafana did not re-query the same data so much, scenes partly fix this but even there it can be a bit cumbersome as it relies on caching the full scene tree.

But caching queries is a pretty tricky problem (and could come with perf costs as well)

Cache key parts

• Queries json model JSON stringified
  • Sadly we would also have to interpolate the full query json string for variables (Which can be costly and would happen again in the data source implementation)
• Time range
• Data source uid
• Adhoc filters + group by

Problems / challanges

• For absolute time ranges, a user can still hit the refresh button to issue a new query. But nothing in the above cache key would change
• Don't cache partial or streaming responses

Many requests are not going through runRequest

While all metric queries and most variable queries go through runRequest all data source meta & series lookup queries. Prometheus / Loki issue many of these, sometimes for each query. It has it's own meta cache to limit requesting same data but but still many duplicated requests.

Anyone, this is just 10min test. Let me know if anyone is interested in this, thinks it's worth pursuing more or have ideas for how to approach it differently.

[ifrost]

Cache is set after getting the result, so if there are multiple requests initiated before the cache is set they will be executed (e.g. on initial render). Another way to apporach it could be shortly debouncing runRequest per hash. Either way, as you said it may come with some perf cost so maybe it'd make sense if it was optional and enabled on case by case basis.

To cache interpolated queries maybe the cache could live closer to the .query() method. There's already queryCachingTTL for backend caching but it's only used in Enterprise.

My gut feeling is that It seems it could be a nice thing to have in general if was opt-in rather than default 🤔

[gillesdemey]

I'd advise some caution when thinking of moving it closer to the query method unless there is a way to opt-out of caching – some teams (including ours, the Alerting team) have already implemented RTK Query in parts of the code base but still call the query() function in queryFn. A double layer of cache would be ... well you know what they say about cache invalidation :D

[torkelo]

@ifrost yea, we could implement a query cache concept similar to react-query to handle that (So multiple queries with same key does not cause multiple real queries).

I originally tried to use the react-query cache but does not look possible.

The point with a cache here is to have a shared cache across different apps / parts of Grafana.

[svennergr]

I think if we would go with that, we should only cache successful data, i.e. no error responses.