You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the underlying problem you're trying to solve?
The OPA HTTP server currently caches only the most recent 100 queries. This works great for many small workloads, but can result in degraded performance in more complex authz scenarios, such as when more than 100 common query types are sent to the same OPA instance in a short time frame.
The problem I'd like to see solved is the current lack of control over the request cache.
Describe the ideal solution
Ideally, I'd like to see a few configuration knobs exposed to the user, which could be provided as part of an OPA config.yaml file.
Properties that I'd expect might be useful to control:
TTLs for cache entries would be a bit more work, but could be a fantastic way to keep cache sizes down across time. (Infrequently-used entries would expire, and automatically get evicted instead of lingering around in memory.)
Describe a "Good Enough" solution
Control of the number of cache entries would be a great start, and having maybe 2-3 different cache eviction strategies to pick from would be incredible. 🙂
Additional Context
The text was updated successfully, but these errors were encountered:
An additional eviction strategy that comes to mind would be to prioritize evicting quick-running queries 🤔; keeping the more expensive (time-wise) results.
This would of course need to be tempered by some other strategy, so we don't end up with a cache full of one-shots.
What is the underlying problem you're trying to solve?
The OPA HTTP server currently caches only the most recent 100 queries. This works great for many small workloads, but can result in degraded performance in more complex authz scenarios, such as when more than 100 common query types are sent to the same OPA instance in a short time frame.
The problem I'd like to see solved is the current lack of control over the request cache.
Describe the ideal solution
Ideally, I'd like to see a few configuration knobs exposed to the user, which could be provided as part of an OPA
config.yaml
file.Properties that I'd expect might be useful to control:
Describe a "Good Enough" solution
Control of the number of cache entries would be a great start, and having maybe 2-3 different cache eviction strategies to pick from would be incredible. 🙂
Additional Context
The text was updated successfully, but these errors were encountered: