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
{{ message }}
This repository has been archived by the owner on Jan 16, 2022. It is now read-only.
We want to express caching in the proxy in terms of attributes. If a specific set of attributes remains constant for a given time and given # of uses, we can use a cached result for Check.
The attributes we have today often do not play well with the above goal because they aren't specific enough, leading to potentially completely ineffective caching. More specifically, there are cases where several different attribute values should be treated similarly from a caching perspective and are not. Some examples of this:
The quintessential example of this is request.size, where the semantics we'd like is "all request.size values < XXX".
Another example is request.time where we'd like to say things like "all requests between 12:00AM and 6:00AM".
Finally, request.url contains method names which we want to operate on specifically, having different cached answers for different methods.
The solution to these problems involves introducing an attribute specialization model within the client such that it can produce derived attributes based on its existing set. These derived attributes would be sufficiently fine-grained to allow effective caching. This can be driven by relatively simple code and simple configuration within the client. For example:
request.size. Generate the request.size.scale attribute which is a string assigned via config based on the range of the size. For example, the config can specify small:0..20, medium:21..200, large:201
request.time. Generate a variety of attributes automatically such as request.time.hour, request.time.dayOfWeek, etc. Also, generate the config-driven request.time.scheduledEvent attribute with stuff like offtimes: 0:00-6:00,18:00-23:59
request.url is broken down per Swagger
In other words, we have specialized attribute processing algebra for a variety of attributes which is intended to produce new finer-grained attributes against which policies are applied in Mixer. To improve caching, we will encourage Mixer config to be authored using these derived attributes when possible.
We need to look at the individual attributes we produce and figure out what kind of specialization makes sense for each, and what kind of config syntax we want to control this. Finally, we need to decide which of these derived attributes are the most useful in the short term in order to prioritize implementation work.
The text was updated successfully, but these errors were encountered:
We want to express caching in the proxy in terms of attributes. If a specific set of attributes remains constant for a given time and given # of uses, we can use a cached result for Check.
The attributes we have today often do not play well with the above goal because they aren't specific enough, leading to potentially completely ineffective caching. More specifically, there are cases where several different attribute values should be treated similarly from a caching perspective and are not. Some examples of this:
The quintessential example of this is request.size, where the semantics we'd like is "all request.size values < XXX".
Another example is request.time where we'd like to say things like "all requests between 12:00AM and 6:00AM".
Finally, request.url contains method names which we want to operate on specifically, having different cached answers for different methods.
The solution to these problems involves introducing an attribute specialization model within the client such that it can produce derived attributes based on its existing set. These derived attributes would be sufficiently fine-grained to allow effective caching. This can be driven by relatively simple code and simple configuration within the client. For example:
request.size. Generate the request.size.scale attribute which is a string assigned via config based on the range of the size. For example, the config can specify small:0..20, medium:21..200, large:201
request.time. Generate a variety of attributes automatically such as request.time.hour, request.time.dayOfWeek, etc. Also, generate the config-driven request.time.scheduledEvent attribute with stuff like offtimes: 0:00-6:00,18:00-23:59
request.url is broken down per Swagger
In other words, we have specialized attribute processing algebra for a variety of attributes which is intended to produce new finer-grained attributes against which policies are applied in Mixer. To improve caching, we will encourage Mixer config to be authored using these derived attributes when possible.
We need to look at the individual attributes we produce and figure out what kind of specialization makes sense for each, and what kind of config syntax we want to control this. Finally, we need to decide which of these derived attributes are the most useful in the short term in order to prioritize implementation work.
The text was updated successfully, but these errors were encountered: