Pending requests: measure time spend waiting on a full queue#97
Pending requests: measure time spend waiting on a full queue#97htuch merged 32 commits intoenvoyproxy:masterfrom
Conversation
- Switch to Envoy@ec47fee6604468bc392937967415c736f19fb22129929881270a1635ad216d87 - Fixes to build with this version - Remove C++ integration tests that broke unrepairably - Add Python-based integration testing - Sets us up with some basic orchestration to run servers (like the one from Nighthawk in these tests) - Add python format checking (CI) / fixing - Update grpc stub generation to a more sane approach Fixes envoyproxy#50 Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Now that we have progressed I think we can drop a couple of entries. Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
…gration-work Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
- Adds a the following fields to the benchmark client proto (and matching CLI args):
```
envoy.api.v2.auth.UpstreamTlsContext tls_context = 13;
uint32 max_pending_requests = 14 [(validate.rules).uint32 = {gte: 1}];
uint32 max_active_requests = 15 [(validate.rules).uint32 = {gte: 1}];
uint32 max_requests_per_connection = 16 [(validate.rules).uint32 = {gte: 1}];
```
This allows for
- cipher suite selection in `https` runs,
- tuning of connection re-use,
- tuning client side request queueing
- tuning the maximum amount of active requests
When specifying `max_pending_requests > 1` the benchmark client will stop guarding the
exact pacing of requests, allowing open-loop test scenarios.
- Unifies validation in the CLI and service paths.
- Consolidates default values into a header and improves handling.
- Updates the options proto to use 32 bits where relevant, as well as
switches fields to WKT's to enable us to make the distinction between
`not-set` and type-default.
Resolves both envoyproxy#45
Resolves envoyproxy#32
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
- Add sample server stats counter expectations - Add tests for cipher suite selection Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Plus some other minor changes addressing review feedback Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
- Pass in the strict validation visitor instead of the NOP implementation - Uncomment a test to prove validation works - Audit NullValidationVisitor everywhere & fix Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
|
This needs #88 to go in first. |
| } | ||
|
|
||
| bool BenchmarkClientHttpImpl::tryStartOne(std::function<void()> caller_completion_callback) { | ||
| if (!cluster_->resourceManager(Envoy::Upstream::ResourcePriority::Default) |
There was a problem hiding this comment.
Not sure I see how this diff relates to the PR description..
There was a problem hiding this comment.
Without this change, we would see the overflow stats rise excessively. With it we will end up reporting the time we spend not being able to queue u a new request as time spend blocking (we indicate we could not by returning false). Hope that clarifies this?
There was a problem hiding this comment.
I think so, but can you add comments and a test?
/wait
There was a problem hiding this comment.
Done, and done. The test is implemented with python, wdyt?
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
| return counters | ||
|
|
||
| def test_h1_mini_stress_test_with_client_side_queueing(self): | ||
| counters = self.mini_stress_test_h1([ |
There was a problem hiding this comment.
For all the actual test_*, can you add Pydoc style comments describing what each one does? This is pretty standard style in Google Python style.
| # we should observe both lots of successfull requests as well as time spend in blocking mode., | ||
| parsed_json = self.runNighthawkClient(args) | ||
| counters = self.getNighthawkCounterMapFromJson(parsed_json) | ||
| self.assertGreater(counters["benchmark.http_2xx"], 1000) |
There was a problem hiding this comment.
This (and below) are coupled with the call site, maybe try and have one source of truth for the number of reqs.
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
When allowing client-side queuing, this makes us report how much time we spend
being waiting on a full queue as blocking.
This allows us to get a sense of how much time we spend in closed loop mode
during a benchmark.
Addendum which fixes #88