http: setting default lazy headermap threshold to 3#16670
http: setting default lazy headermap threshold to 3#16670mattklein123 merged 8 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
|
Can we add a test that demonstrates the new default? Thanks cc @mattklein123 @alyssawilk in case there are thoughts on what the default should be |
| ``envoy.reloadable_features.send_strict_1xx_and_204_response_headers`` | ||
| (do not send 1xx or 204 responses with these headers). Both are true by default. | ||
| * http: serve HEAD requests from cache. | ||
| * http: set the default lazy headermap threshold to 3, which defines the minimal number of headers in a |
There was a problem hiding this comment.
Thanks for improving the defaults - I like removing O(n) problems from the default deployment :-)
I think it's not clear from this what the user-visible change is likely to be. I assume there's going to be some user-visible change or we'd just have done a runtime guard of "use_efficient_header_map" and planned to deprecate the old code.
Is it the case that if there's more than 3 non-inline headers, that Envoy will elide multiple header keys into a single entry?
There was a problem hiding this comment.
+1 on making this more clear, and potentially even adding a section on this to the HTTP arch overview?
Stepping back, I feel like if we are going to keep this configurability it should probably be a config option or a CLI option, but that would be a larger change. At minimum I would recommend more documentation.
There was a problem hiding this comment.
Nice, can you ref link to the new section you added in the arch overview docs? (You will need to add an anchor above that new section.)
There was a problem hiding this comment.
sorry I guess I'm still not clear on the user-visible change
Does this just add an extra data structure for fast look-up, but ordering and inlining will remain the same? If so why aren't we just turning this on by default, seeing if anyone complains, and removing the old option? Basically any request and response headers are going to go above 3, so this seems like a lot of complexity for a feature that'd always be on unless someone turns it off to make their own operations more expensive? :-P
There was a problem hiding this comment.
I tend to agree that if the actual number we are picking is 3 (as opposed to 10 for example), having it always on and hard coded internally is probably OK. It wouldn't turn on for many trailers cases but that is a minor point.
There was a problem hiding this comment.
ah, trailers is a good counterpoint - often only one or two of those. might be worth commenting somewhere the value was selected to result in doing fast mapping for the one and not the other. I wonder if this catches most 100-continue or if they pass through as well. either way feel free to merge once CI passes.
mattklein123
left a comment
There was a problem hiding this comment.
Awesome, thanks for following up on this.
/wait
| ``envoy.reloadable_features.send_strict_1xx_and_204_response_headers`` | ||
| (do not send 1xx or 204 responses with these headers). Both are true by default. | ||
| * http: serve HEAD requests from cache. | ||
| * http: set the default lazy headermap threshold to 3, which defines the minimal number of headers in a |
There was a problem hiding this comment.
+1 on making this more clear, and potentially even adding a section on this to the HTTP arch overview?
Stepping back, I feel like if we are going to keep this configurability it should probably be a config option or a CLI option, but that would be a larger change. At minimum I would recommend more documentation.
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
@adisuissa can we land this? Can you merge main? |
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
…hreshold Signed-off-by: Adi Suissa-Peleg <adip@google.com>
…hreshold Signed-off-by: Adi Suissa-Peleg <adip@google.com>
mattklein123
left a comment
There was a problem hiding this comment.
Awesome, thanks. Per offline discussion let's get this in right after we cut the release just so we don't do something high risk right before.
/wait
| ``envoy.reloadable_features.send_strict_1xx_and_204_response_headers`` | ||
| (do not send 1xx or 204 responses with these headers). Both are true by default. | ||
| * http: serve HEAD requests from cache. | ||
| * http: set the default lazy headermap threshold to 3, which defines the minimal number of headers in a |
There was a problem hiding this comment.
Nice, can you ref link to the new section you added in the arch overview docs? (You will need to add an anchor above that new section.)
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
…hreshold Signed-off-by: Adi Suissa-Peleg <adip@google.com>
|
Thanks, can you merge main and we can get this in? /wait |
…hreshold Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Commit Message: setting default lazy headermap threshold to 3
Additional Description:
PR #12656 introduced the
envoy.http.headermap.lazy_map_min_sizeconfiguration parameter, that sets the threshold value for the lazy headermap - the number of headers in the headermap after which the headermap will use an underlying dictionary to map the headers.This PR sets the default value to 3, which ensures that the headermap operations have a linear time-complexity (see #13333).
Risk Level: Medium - sets a different default threshold value.
Testing: None, tests already exist.
Docs Changes: None.
Release Notes: Added note.
Platform Specific Features: N/A.
Fixes #13333
Signed-off-by: Adi Suissa-Peleg adip@google.com