[Bandwidth-Limit] Add response trailers for bandwidth delay#18267
[Bandwidth-Limit] Add response trailers for bandwidth delay#18267htuch merged 20 commits intoenvoyproxy:mainfrom zhiyong-gayang:main
Conversation
Signed-off-by: gayang <gayang@microsoft.com>
|
Hi @garyyang2002, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
| stats_(generateStats(config.stat_prefix(), scope)), | ||
| request_delay_trailer_(config.response_trailer_prefix().empty() | ||
| ? DefaultRequestDelayTrailer | ||
| : Http::LowerCaseString(config.response_trailer_prefix() + "-" + |
There was a problem hiding this comment.
absl::StrCat might be a better option here.
There was a problem hiding this comment.
strcat seems can't concatenate two const strings, maybe another way I don't know.
| if (response_latency_) { | ||
| const auto& config = getConfig(); | ||
|
|
||
| auto response_duration = response_latency_.get()->elapsed().count(); |
There was a problem hiding this comment.
We are planning to make stats write only, except for stat sinks. This code will end up broken in this case. Can a timestamp be used in this case?
There was a problem hiding this comment.
To get from the stats will give me a consistent delay value for response trail and the stats.
Make stats write only seems a challenge work, can we read the stats here before you have a concrete plan how to remove the stats read reference.
| // request: response_trailer_prefix + "-bandwidth-request-delay-ms" | ||
| // response: response_trailer_prefix + "-bandwidth-response-delay-ms" | ||
| // If EnableMode is DISABLED or REQUEST or delay time = 0, the trailer will not be set. | ||
| string response_trailer_prefix = 6; |
There was a problem hiding this comment.
Do you want to make these trailers optional, such that an operator can enable or disable it?
There was a problem hiding this comment.
make sense, added property to enable it.
| std::unique_ptr<Envoy::Extensions::HttpFilters::Common::StreamRateLimiter> response_limiter_; | ||
| Stats::TimespanPtr request_latency_; | ||
| Stats::TimespanPtr response_latency_; | ||
| uint64_t request_duration_ = 0; |
There was a problem hiding this comment.
Would you want to use std::chrono::milliseconds to make units explicit?
There was a problem hiding this comment.
the source of request_duration_ is uint64, and this variable will be write to response trailer as string, use milliseconds will need additional convert from unit64 to milliseconds, then to string.
There was a problem hiding this comment.
The source is CompletableTimespan::ellapsed which returns std::milliseconds. I think you should keep the type around until you need to write it into the trailer.
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
htuch
left a comment
There was a problem hiding this comment.
Much clearer comments, a bunch of RST nits.
/wait
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/bandwidth_limit/v3alpha/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
| response_incoming_size, GAUGE, Size in bytes of incoming response data to bandwidth limiter | ||
| response_allowed_size, GAUGE, Size in bytes of outgoing response data from bandwidth limiter | ||
| response_incoming_size, Counter, Size in bytes of incoming response data to bandwidth limiter | ||
| response_allowed_size, Counter, Size in bytes of outgoing response data from bandwidth limiter |
There was a problem hiding this comment.
What does it mean to change from gauge to counter here?
There was a problem hiding this comment.
Counter seems more reasonable for incoming size and allowed size, which allow us to calculate the incoming and allowed size per second for better monitoring of the bandwidth usage.
There was a problem hiding this comment.
My understanding is counter use less memory than histogram, and for this case, counter is good enough.
There was a problem hiding this comment.
The original change looks buggy. I suspect the original intent was to keep track how much data the bandwidth limit filter has currently in its buffers. But I think the call to decrement the gauge when data is removed from the buffer is missing. This may have happened when the stream_rate_limiter.cc was refactored.
I suggest filing an Issue for the gauge value not being tracked correctly and keeping it as gauge. I do not think there is particular value in the counter, the number is almost meaningless.
There was a problem hiding this comment.
Make sense, changed back to Gauge, and open the issue to track.
#18703
api/envoy/extensions/filters/http/bandwidth_limit/v3/bandwidth_limit.proto
Outdated
Show resolved
Hide resolved
|
@yanavlasov can you take this review through implementation review? Thanks. |
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
| : Http::LowerCaseString(config.response_trailer_prefix() + "-" + | ||
| DefaultResponseDelayTrailer.get())), |
There was a problem hiding this comment.
| : Http::LowerCaseString(config.response_trailer_prefix() + "-" + | |
| DefaultResponseDelayTrailer.get())), | |
| : Http::LowerCaseString(absl::StrCat(config.response_trailer_prefix(), "-", | |
| DefaultResponseDelayTrailer.get()))), |
There was a problem hiding this comment.
fixed, thanks.
| stats_(generateStats(config.stat_prefix(), scope)), | ||
| request_delay_trailer_(config.response_trailer_prefix().empty() | ||
| ? DefaultRequestDelayTrailer | ||
| : Http::LowerCaseString(config.response_trailer_prefix() + "-" + |
| std::unique_ptr<Envoy::Extensions::HttpFilters::Common::StreamRateLimiter> response_limiter_; | ||
| Stats::TimespanPtr request_latency_; | ||
| Stats::TimespanPtr response_latency_; | ||
| uint64_t request_duration_ = 0; |
There was a problem hiding this comment.
The source is CompletableTimespan::ellapsed which returns std::milliseconds. I think you should keep the type around until you need to write it into the trailer.
| // Adds encoded trailers. May only be called in encodeData when end_stream is set to true. | ||
| // If upstream has trailers, addEncodedTrailers won't be called | ||
| bool trailer_added = false; | ||
| if (end_stream) { |
There was a problem hiding this comment.
This should also check enableResponseTrailers()
There was a problem hiding this comment.
fixed, thanks.
| const auto* config = dynamic_cast<const FilterConfig*>(route_config.get()); | ||
| EXPECT_EQ(config->limit(), 10); | ||
| EXPECT_EQ(config->fillInterval().count(), 50); | ||
| // default trailers |
There was a problem hiding this comment.
Can you also add tests for the enable_response_trailers config value, please?
There was a problem hiding this comment.
added, thanks.
Signed-off-by: gayang <gayang@microsoft.com>
…incoming_size, response_allowed_size back to gauge Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
Signed-off-by: gayang <gayang@microsoft.com>
Commit Message:
Additional Description: This is useful when downstream want to understand how much delays that is caused by bandwidth limit filter.
Risk Level: Low
Testing: UT added.
Docs Changes: Updated.
Release Notes: Added.
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]