Use prepared queries in the OPA server #1567
Assignees
Comments
|
Let's figure out how much memory the prepared queries take and then decide on the caching strategy. Enabling this for the default decision is a no brainer. For /v1/data we could enable it for some number of paths. Defaulting to a large value (e.g., 1,000 distinct paths) might be fine if the memory usage is low (which it should be). |
patrick-east
added a commit
to patrick-east/opa
that referenced
this issue
Dec 17, 2019
This adds in caching of prepared queries for versioned and unversioned data queries (POST/GET to `/`, `/data`, and `/v1/data`). The cache has a max size of 100 and just starts acting as a circular buffer for queries (FIFO, no smarts for LRU caching or anything). It seems like it would be unlikely for these API's to hit the cache max size. Most OPA use-cases have a single query that is re-used over and over with different inputs. There is a new metric `counter_server_query_cache_hit` which will show whether or not a request used the query cache or not. It is there primarily to help explain away why sometimes a handful of the other metrics aren't there (the query parse/compile/etc). In the future this could be added to the query API's too. This change does not touch anything other than the "data" API's. Closes: open-policy-agent#1567 Signed-off-by: Patrick East <east.patrick@gmail.com>
patrick-east
added a commit
that referenced
this issue
Dec 18, 2019
This adds in caching of prepared queries for versioned and unversioned data queries (POST/GET to `/`, `/data`, and `/v1/data`). The cache has a max size of 100 and just starts acting as a circular buffer for queries (FIFO, no smarts for LRU caching or anything). It seems like it would be unlikely for these API's to hit the cache max size. Most OPA use-cases have a single query that is re-used over and over with different inputs. There is a new metric `counter_server_query_cache_hit` which will show whether or not a request used the query cache or not. It is there primarily to help explain away why sometimes a handful of the other metrics aren't there (the query parse/compile/etc). In the future this could be added to the query API's too. This change does not touch anything other than the "data" API's. Closes: #1567 Signed-off-by: Patrick East <east.patrick@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is support for preparing and re-using Rego queries so save time with recompiling everything except for the input https://godoc.org/github.com/open-policy-agent/opa/rego#example-Rego-PrepareForEval
The OPA server has support for partially evaluating and then re-using those partial evaluations https://www.openpolicyagent.org/docs/latest/rest-api/#query-parameters-4 , this would work similarly to help speed up repeat queries with different inputs.
We would need to be careful not to take up too much memory with the prepared queries being cached.
The text was updated successfully, but these errors were encountered: