Open loop sync/async multithreaded testing#1948
Open loop sync/async multithreaded testing#1948ctiller merged 51 commits intogrpc:masterfrom vjpai:poisson
Conversation
and use nanoseconds
Conflicts: Makefile
…ync tests as well
… still be alive at this time Conflicts: test/cpp/qps/client_sync.cc
Conflicts: test/cpp/qps/client_sync.cc
Conflicts: Makefile build.json
Conflicts: Makefile
Conflicts: Makefile
Conflicts: Makefile test/cpp/qps/client_async.cc test/cpp/qps/qpstest.proto
|
I've asked @dgquintas for a review since he had been reviewing my earlier failed PR before I closed it. |
There was a problem hiding this comment.
These distributions need a few lines of documentation on what the distribution looks like.
I'd even take links to Wikipedia articles :)
|
What if we had something like: namespace grpc {
class Alarm {
public:
// emits a completion to cq with tag 'tag' on completion
void Start(CompletionQueue* cq, void* tag, some_time_type deadline);
void Cancel();
};
}We'd need a C api to mirror it (grpc_cq_alarm_XXX?), and then we could leverage the existing alarm list implementation to drive it. |
|
That suggestion sounds helpful. I can look over the async code and give you an estimate of how much it would save. |
There was a problem hiding this comment.
the formatting of these three lines looks funny. Is this how clang-format does it?
There was a problem hiding this comment.
Yes, this was courtesy of clang-format.
Also remove the parameterized constructor for InterarrivalTimer and only keep the init function.
test/cpp/qps/client_async.cc
Outdated
There was a problem hiding this comment.
Better, will just directly place the reference into the code below.
|
Hi there, any more comments, or is this a go at this point? |
|
Can you add a variation of qps_test that sets up and runs a fixed rate test for ten seconds on localhost? It'll let this code get some more miles on Travis. |
|
OK, will do. On Fri, Jun 5, 2015, 6:27 PM Craig Tiller [email protected] wrote:
|
regularly. Also, convert qps_test to test, from benchmark
|
So, the new tests are in. The tests themselves pass, but coveralls seems to be stuck. |
Open loop sync/async multithreaded testing
4 participants
This PR adds the ability to do open-loop testing with various random distributions (though only Poisson makes a lot of sense). You can specify the rate as a load parameter, and the client config proto is expanded accordingly.
Note that using open-loop testing effectively will typically require you to set a greater value for outstanding_rpcs_per_channel than you would with closed loop, as you need some slack to make up for times when the channels aren't able to keep up with natural variations in the random distribution.
What's not supported: benchmarking for open-loop async streaming. This is an uncommonly used method of communication, so there wasn't a strong desire to incorporate the additional complexity required to benchmark it.