-
Notifications
You must be signed in to change notification settings - Fork 94
Finalize emission and tracking of latencies in response headers #500
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
Changes from 37 commits
c226497
c6697de
28e0d34
94ad984
933c589
a1691ec
740d0ca
1afe2f1
ae0c08e
3487e19
1d1f03a
a9d99eb
0aa8630
db01e40
5e48513
d9569cb
cf1170c
421feb8
af148ea
e813e75
505495c
5405dc9
d858b55
3cf32b8
35aee47
027c00f
70502e1
a55bbe7
d199313
a16d8dd
f3008d9
7774e2d
937fd88
8152829
64cb19c
af60b8d
3996c65
228934a
00b6861
68ed58a
74f9717
594bbbe
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -43,8 +43,9 @@ bazel build -c opt //:nighthawk | |
| ``` | ||
| USAGE: | ||
|
|
||
| bazel-bin/nighthawk_client [--stats-flush-interval <uint32_t>] | ||
| [--stats-sinks <string>] ... | ||
| bazel-bin/nighthawk_client [--response-header-with-latency-input | ||
| <string>] [--stats-flush-interval | ||
| <uint32_t>] [--stats-sinks <string>] ... | ||
| [--no-duration] [--simple-warmup] | ||
| [--request-source <uri format>] [--label | ||
| <string>] ... [--multi-target-use-https] | ||
|
|
@@ -80,6 +81,12 @@ format> | |
|
|
||
| Where: | ||
|
|
||
| --response-header-with-latency-input <string> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the meaning here is a little hard to parse from the name / comment combo. How do you feel about response_latency_header_name? |
||
| Set an optional response header name, whose values will be tracked in | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For the description, can I suggest this edit to the first sentence: |
||
| a latency histogram if set. Can be used in tandem with the test server | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For the second sentence, can we edit to something like: (Adding in the word response option clarifies where the reader should look for the definition of that) |
||
| "emit_previous_request_delta_in_response_header" option to get a sense | ||
| of elapsed time between request arrivals. Default: "" | ||
|
|
||
| --stats-flush-interval <uint32_t> | ||
| Time interval (in seconds) between flushes to configured stats sinks. | ||
| Default: 5. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -46,7 +46,8 @@ class StreamDecoder : public Envoy::Http::ResponseDecoder, | |
| Statistic& response_body_sizes_statistic, Statistic& origin_latency_statistic, | ||
| HeaderMapPtr request_headers, bool measure_latencies, uint32_t request_body_size, | ||
| Envoy::Random::RandomGenerator& random_generator, | ||
| Envoy::Tracing::HttpTracerSharedPtr& http_tracer) | ||
| Envoy::Tracing::HttpTracerSharedPtr& http_tracer, | ||
| std::string response_header_with_latency_input) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm a little surprised by your use of a std::string copy with std::move here, as opposed to having this be an absl::string_view (or const std::string&, whicever is more common within our code). And then having doing response_header_with_latency_input_(response_header_with_latency_input), which I'm pretty sure just works. This suggestion is more in line with the style I'm familiar with. Is there a strong reason not to do that?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch. I'm surprised too, I must have grown tired of the tried and proven path in this repo :-) Using absl::string_view now. |
||
| : dispatcher_(dispatcher), time_source_(time_source), | ||
| decoder_completion_callback_(decoder_completion_callback), | ||
| caller_completion_callback_(std::move(caller_completion_callback)), | ||
|
|
@@ -57,7 +58,8 @@ class StreamDecoder : public Envoy::Http::ResponseDecoder, | |
| request_headers_(std::move(request_headers)), connect_start_(time_source_.monotonicTime()), | ||
| complete_(false), measure_latencies_(measure_latencies), | ||
| request_body_size_(request_body_size), stream_info_(time_source_), | ||
| random_generator_(random_generator), http_tracer_(http_tracer) { | ||
| random_generator_(random_generator), http_tracer_(http_tracer), | ||
| response_header_with_latency_input_(std::move(response_header_with_latency_input)) { | ||
| if (measure_latencies_ && http_tracer_ != nullptr) { | ||
| setupForTracing(); | ||
| } | ||
|
|
@@ -119,6 +121,7 @@ class StreamDecoder : public Envoy::Http::ResponseDecoder, | |
| Envoy::Tracing::HttpTracerSharedPtr& http_tracer_; | ||
| Envoy::Tracing::SpanPtr active_span_; | ||
| Envoy::StreamInfo::UpstreamTiming upstream_timing_; | ||
| const std::string response_header_with_latency_input_; | ||
| }; | ||
|
|
||
| } // namespace Client | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -179,7 +179,7 @@ class BenchmarkClientHttpTest : public Test { | |
| void setupBenchmarkClient(const RequestGenerator& request_generator) { | ||
| client_ = std::make_unique<Client::BenchmarkClientHttpImpl>( | ||
| *api_, *dispatcher_, store_, statistic_, false, cluster_manager_, http_tracer_, "benchmark", | ||
| request_generator, true); | ||
| request_generator, true, ""); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a lot of arguments here. Would it be okay if we added comments helping users track the corresponding parameter under use? For the new one, it'd be |
||
| } | ||
|
|
||
| uint64_t getCounter(absl::string_view name) { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| admin: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we add a comment at the top of this, explaining its purpose in just a sentence, and draw attention to the relevant/unique part of the configuration (which I think is the time-tracking filter) |
||
| access_log_path: $tmpdir/nighthawk-test-server-admin-access.log | ||
| profile_path: $tmpdir/nighthawk-test-server.prof | ||
| address: | ||
| socket_address: { address: $server_ip, port_value: 0 } | ||
| static_resources: | ||
| listeners: | ||
| - address: | ||
| socket_address: | ||
| address: $server_ip | ||
| port_value: 0 | ||
| filter_chains: | ||
| - filters: | ||
| - name: envoy.http_connection_manager | ||
| config: | ||
| generate_request_id: false | ||
| codec_type: auto | ||
| stat_prefix: ingress_http | ||
| route_config: | ||
| name: local_route | ||
| virtual_hosts: | ||
| - name: service | ||
| domains: | ||
| - "*" | ||
| http_filters: | ||
| - name: time-tracking | ||
| config: | ||
| emit_previous_request_delta_in_response_header: x-origin-request-receipt-delta | ||
| - name: test-server | ||
| config: | ||
| response_body_size: 10 | ||
| - name: envoy.router | ||
| config: | ||
| dynamic_stats: false | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -700,6 +700,24 @@ def test_cancellation_with_infinite_duration(http_test_server_fixture): | |
| asserts.assertCounterGreaterEqual(counters, "benchmark.http_2xx", 1) | ||
|
|
||
|
|
||
| @pytest.mark.parametrize('server_config', | ||
| ["nighthawk/test/integration/configurations/nighthawk_track_timings.yaml"]) | ||
| def test_http_h1_response_header_latency_tracking(http_test_server_fixture): | ||
| """Test emission and tracking of response header latencies. | ||
|
|
||
| Run the CLI configured to track latencies delivered by response header from the test-server | ||
| which is set up emit those. Ensure the expected histogram is observed. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: set up to emit those
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Can we instead say ensure the histogram receives the correct number of inputs or something? |
||
| """ | ||
| parsed_json, _ = http_test_server_fixture.runNighthawkClient([ | ||
| http_test_server_fixture.getTestServerRootUri(), "--connections", "1", "--rps", "100", | ||
| "--duration", "100", "--termination-predicate", "benchmark.http_2xx:99", | ||
| "--response-header-with-latency-input", "x-origin-request-receipt-delta" | ||
| ]) | ||
| global_histograms = http_test_server_fixture.getNighthawkGlobalHistogramsbyIdFromJson(parsed_json) | ||
| asserts.assertEqual( | ||
| int(global_histograms["benchmark_http_client.origin_latency_statistic"]["count"]), 99) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we add a second integration test that works as a crash test of sorts, for adding in the header but receiving no responses that include that header? Not sure of the exact correct assertions. We would expect it to work, but for origin_latency_statistic to equal 0, I think. Working could be defined as the responses_xxx counter increasing?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done; we now test using two server side configurations, one with the new time-tracking extension enabled, and one that doesn't have it set up. We check expectations based on which one we're testing. Let me know if that looks good to you. (68ed58a) |
||
|
|
||
|
|
||
| def _run_client_with_args(args): | ||
| return utility.run_binary_with_args("nighthawk_client", args) | ||
|
|
||
|
|
||
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.
No changes here requested, and I think we're in agreement here, but eventually I think we need to move away from TCLAP automating this, because there are now so many flags that it's become difficult to find what you need (e.g. rps, duration).
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.
Yeah, I agree.