route config: Allow to configure direct response body size#14778
route config: Allow to configure direct response body size#14778htuch merged 17 commits intoenvoyproxy:mainfrom dio:dr-route-config
Conversation
This patch allows configuring direct response body size, by setting route config max_direct_response_body_size_bytes. Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
htuch
left a comment
There was a problem hiding this comment.
Thanks for the PR @dio! I'll take this review since @mattklein123 is out.
/wait
| // .. warning:: | ||
| // | ||
| // The content of :ref:`direct response body | ||
| // <envoy_api_field_config.route.v3.DirectResponseAction.body>` will be held in memory. |
There was a problem hiding this comment.
Can you be more specific here? I.e. is the concern it's held in configuration memory, or in buffers on the response path, etc.
There was a problem hiding this comment.
Tried to add more description on this. Please let me know if I put it wrongly.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
htuch
left a comment
There was a problem hiding this comment.
LGTM modulo comment in route.proto. Thanks!
/wait
| // <envoy_api_field_config.route.v3.DirectResponseAction.body>` will be held in memory. | ||
| // Envoy currently holds the content of :ref:`direct response body | ||
| // <envoy_api_field_config.route.v3.DirectResponseAction.body>` in memory. Be careful setting | ||
| // this to be larger than the default 4KB. The default is limited to 4KB to keep the proxy's |
There was a problem hiding this comment.
Is this the only reason? My understanding is we also want to avoid flooding watermarked buffers. E.g. if the buffer limits are 128KB and we dump 10MB in a direct response, that will be queued. @alyssawilk for thoughts.
There was a problem hiding this comment.
Oh, this is a gem. Thanks, @htuch! I didn't know that. I will do more digging. And, yes, I'll be very thankful if @alyssawilk can give some thoughts on this.
There was a problem hiding this comment.
I don't think it'd be queued, I think we'd disable reading from a nonexistent upstream (and risk OOMs if there were lots of direct responses)
I think it'd be fine to allow larger responses (though I'd be inclined to add a warning note in the API about it not being subject to memory guards so use with care) but suggest an integration test to make sure it all works as I think it should :-)
There was a problem hiding this comment.
I have added "standard" cases to the direct response integration test. If you think we need to cover more cases, please let me know. re: Buffer limit, I have a test case that sends 1000 * 4K so I think it's enough.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
htuch
left a comment
There was a problem hiding this comment.
LGTM, but defer to @alyssawilk for a pass/merge.
| // Envoy currently holds the content of :ref:`direct response body | ||
| // <envoy_api_field_config.route.v3.DirectResponseAction.body>` in memory. Be careful setting | ||
| // this to be larger than the default 4KB, since the allocated memory for direct response body | ||
| // is not being subject to memory guards. |
There was a problem hiding this comment.
I might phrase this as "data plane buffering controls" rather than "memory guards".
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
|
/retest |
|
Retrying Azure Pipelines: |
alyssawilk
left a comment
There was a problem hiding this comment.
Looks good overall - I'm sure this will be really useful to a lot of users - thanks for adding it!
|
|
||
| TEST_P(DirectResponseIntegrationTest, DirectResponseBodySizeLarge) { | ||
| // Test with a large direct response body size. | ||
| testDirectResponseBodySize(1000 * 4096); |
There was a problem hiding this comment.
mind also setting
config_helper_.setBufferLimits(1024, 1024);
for this one?
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
| * http: change frame flood and abuse checks to the upstream HTTP/2 codec to ON by default. It can be disabled by setting the `envoy.reloadable_features.upstream_http2_flood_checks` runtime key to false. | ||
| * overload: add support for scaling :ref:`transport connection timeouts<envoy_v3_api_enum_value_config.overload.v3.ScaleTimersOverloadActionConfig.TimerType.TRANSPORT_SOCKET_CONNECT>`. This can be used to reduce the TLS handshake timeout in response to overload. | ||
| * route config: added :ref:`max_direct_response_body_size_bytes <envoy_v3_api_field_config.route.v3.RouteConfiguration.max_direct_response_body_size_bytes>` to set maximum :ref:`direct response body <envoy_v3_api_field_config.route.v3.DirectResponseAction.body>` size in bytes. If not specified the default remains 4096 bytes. | ||
| * server: added :ref:`fips_mode <statistics>` statistic. |
Commit Message: This patch adds
max_direct_response_body_size_bytesto set the maximum bytes of the direct response body size (in bytes). The config is added as a field inRouteConfiguration.Additional Description: Reviving #13487 with a slightly different approach (add the config to
RouteConfigurationinstead of directly per direct response config entry).Risk Level: Low, since the default behavior is preserved.
Testing: Updated to test the newly introduced config.
Docs Changes: Updated.
Release Notes: Added.
Fixes #13422
Signed-off-by: Dhi Aurrahman dio@rockybars.com