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
Specifically to optimize the pre-processing of per-route config. Here is the proposal
like to clarify how per_route_config_sha can be used.
A filter needs to preprocess the per_route_config.
obj = pre_process(pre_route_config);
Such pre-processing can be slow, it should NOT be performed for each request. One way to optimize it is to save the preprocessed "obj" in some global config. When a request comes, the filter just needs to detect if per_route_config has been changed. Without "sha" map, the filter needs to serialize the proto and sha it to detect the config change. If per-route config is big, these two steps can be slow too.
Another option is to add a new function in FilterFactory
This function will be called when RDS receives new route tables, This will give filter chance to preprocess per_route config and save the pre-processed obj into its global map (not pre-request).
Description:
This is referring to the new per_route_config added in envoyproxy/data-plane-api#605 (comment)
Specifically to optimize the pre-processing of per-route config. Here is the proposal
like to clarify how per_route_config_sha can be used.
A filter needs to preprocess the per_route_config.
obj = pre_process(pre_route_config);
Such pre-processing can be slow, it should NOT be performed for each request. One way to optimize it is to save the preprocessed "obj" in some global config. When a request comes, the filter just needs to detect if per_route_config has been changed. Without "sha" map, the filter needs to serialize the proto and sha it to detect the config change. If per-route config is big, these two steps can be slow too.
Another option is to add a new function in FilterFactory
void setRouteConfig(string unique_route_id, Struct config) PURE;
This function will be called when RDS receives new route tables, This will give filter chance to preprocess per_route config and save the pre-processed obj into its global map (not pre-request).
as global_map[ route_id ] = obj;
During request, obj can be retrieved as
obj = global_map[ filter_callback->route()->unique_route_id() ];
This is better than first approach, the pre-process is done in the config thread, not at worker thread.
Agreed that, such optimization can be done in the later phase.
The text was updated successfully, but these errors were encountered: