-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
router: add benchmarks for route matching #13320
router: add benchmarks for route matching #13320
Conversation
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@envoyproxy/senior-maintainers
Looks great modulo one nit, and senior maintainer approval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment, thank you!
/wait
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for improving benchmark coverage.
|
||
envoy_cc_benchmark_binary( | ||
name = "config_impl_speed_test", | ||
srcs = ["config_impl_speed_test.cc"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an open conversation about name of these targets and source files in #13327
speed_test makes sense for consistency with current sources, but calling them benchmark and benchmark_test may be better long term. Let's see what we decide on that other PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll wait for a few days.
Signed-off-by: Teju Nareddy <[email protected]>
# Conflicts: # test/common/router/BUILD Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
@jmarantz Antonio is out this week. Would you mind taking a look at this? I'm not sure what is still outstanding. |
) Previously, we made a single route when running ESPv2 in sidecar mode. But now we plan to deprecate the path matcher filter and support configuring timeouts for the local backend (#321). To do this, we should switch to configuring the Envoy route table for individual routes for even the local backend. There is one extra feature introduced by this PR: We need to support matching wildcard HTTP Methods when using a [Custom Http Pattern](https://github.com/googleapis/googleapis/blob/cb7fc620590382a4a2ea6ffdf6f51ae0e77bbbb5/google/api/http.proto#L343). This just required an if statement and extra test in `route_generator.go`. **High-risk change** Summarized comments from me and @qiwzhang: > We have to use regex on “path” to support url_template. But path_matcher supports many complicated forms that regex could not support. Currently we use these regex to replace url templates, but not all templates are supported. > I think it is fine, our endpoints users are not using very complicated url templates. We only need to support the url templates from openapi spec, and options.http.rules from grpc proto file. We are still in Beta (not GA), so it should be fine. **Testing Done** - Fix lots of unit and integration tests. - Micro benchmark of the performance impact of switching to per-route config instead of path prefix: envoyproxy/envoy#13320 Signed-off-by: Teju Nareddy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great with one minor comment to address parallel to @envoyproxy/senior-maintainers review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, LGTM other than remaining comment.
/wait
Signed-off-by: Teju Nareddy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Commit Message:
router: add benchmarks for route matching
Additional Description:
Measure the speed of doing a route match against a route table of varying sizes. Why? Currently, route matching is linear in first-to-win ordering.
We benchmark with 3 different type of route matchers: exact path, path prefix, and regex that represents common OpenAPI path templating.
Here are the timings I get when running on my workstation (compiled in
opt
). As expected, route matching isO(n)
based on the route table size.Risk Level:
None
Testing:
Added benchmark
Docs Changes:
None
Release Notes:
None