Get desktop application:
View/edit binary Protocol Buffers messages
One request followed by one response. The server returns the client payload as-is.
Repeated sequence of one request followed by one response. Should be called streaming ping-pong The server returns the client payload as-is on each response
Single-sided unbounded streaming from client to server The server returns the client payload as-is once the client does WritesDone
Single-sided unbounded streaming from server to client The server repeatedly returns the client payload as-is
Two-sided unbounded streaming between server to client Both sides send the content of their own choice to the other
A service used to control reconnect server.
For reconnect interop test only. Client tells server what reconnection parameters it used.
For reconnect interop test only. Server tells client whether its reconnects are following the spec and the reconnect backoffs it saw.
Report results of a QPS test benchmark scenario.
Results of a single benchmark scenario.
Inputs used to run the scenario.
Histograms from all clients merged into one histogram.
Client stats for each client
Server stats for each server
Number of cores available to each server
An after-the-fact computed summary
Information on success or failure of each worker
Number of failed requests (one row per status code seen)
A simple service to test the various types of RPCs and experiment with performance with various types of payload.
One empty request followed by one empty response.
One request followed by one response.
One request followed by one response. Response has cache control headers set such that a caching HTTP proxy (such as GFE) can satisfy subsequent requests.
One request followed by a sequence of responses (streamed download). The server returns the payload with client desired type and sizes.
A sequence of requests followed by one response (streamed upload). The server returns the aggregated size of client payload as the result.
Client-streaming request.
Optional input payload sent along with the request.
Whether the server should expect this request to be compressed. This field is "nullable" in order to interoperate seamlessly with servers not able to implement the full compression tests by introspecting the call to verify the request's compression status.
Client-streaming response.
Aggregated size of payloads received from the client.
A sequence of requests with each request served by the server immediately. As one request could lead to multiple responses, this interface demonstrates the idea of full duplexing.
A sequence of requests followed by a sequence of responses. The server buffers all the client requests and then serves them in order. A stream of responses are returned to the client when the server starts with first request.
The test server will not implement this method. It will be used to test the behavior when clients call unimplemented methods.
A simple service NOT implemented at servers so clients can test for that case.
A call that no server should implement
Start server with specified workload. First request sent specifies the ServerConfig followed by ServerStatus response. After that, a "Mark" can be sent anytime to request the latest stats. Closing the stream will initiate shutdown of the test server and once the shutdown has finished, the OK status is sent to terminate this RPC.
the port bound by the server
Number of cores available to the server
Start client with specified workload. First request sent specifies the ClientConfig followed by ClientStatus response. After that, a "Mark" can be sent anytime to request the latest stats. Closing the stream will initiate shutdown of the test client and once the shutdown has finished, the OK status is sent to terminate this RPC.
Just return the core count - unary call
(message has no fields)
Number of cores available on the server
Quit this worker
TODO(dgq): Go back to using well-known types once https://github.com/grpc/grpc/issues/6980 has been fixed. import "google/protobuf/wrappers.proto";
Used in:
, ,The bool value.
Used in:
Used in:
,Used in:
,List of targets to connect to. At least one target needs to be specified.
How many concurrent RPCs to start for each channel. For synchronous client, use a separate thread for each outstanding RPC.
Number of independent client channels to create. i-th channel will connect to server_target[i % server_targets.size()]
Only for async client. Number of threads to use to start/manage RPCs.
The requested load for the entire client (aggregated over all the threads).
Specify the cores we should run the client on, if desired
If we use an OTHER_CLIENT client_type, this string gives more detail
Number of threads that share each completion queue
Number of messages on a stream before it gets finished/restarted
Used in:
,Latency histogram. Data points are in nanoseconds.
See ServerStats for details.
Number of failed requests (one row per status code seen)
Number of polls called inside completion queue
Used in:
Many languages support a basic distinction between using sync or async client, and this allows the specification
used for some language-specific variants
Once an RPC finishes, immediately start a new one. No configuration parameters needed.
Used in:
(message has no fields)
TODO (vpai): Fill this in once the details of complex, representative protos are decided
Used in:
(message has no fields)
A protobuf representation for grpc status. This is used by test clients to specify a status that the server should attempt to return.
Used in:
,An empty message that you can re-use to avoid defining duplicated empty messages in your project. A typical example is to use it as argument or the return value of a service API. For instance: service Foo { rpc Bar (grpc.testing.Empty) returns (grpc.testing.Empty) { }; };
Used as request type in: ReconnectService.Stop, TestService.EmptyCall, TestService.UnimplementedCall, UnimplementedService.UnimplementedCall
Used as response type in: ReconnectService.Start, TestService.EmptyCall, TestService.UnimplementedCall, UnimplementedService.UnimplementedCall
(message has no fields)
Histogram data based on grpc/support/histogram.c
Used in:
,Histogram params based on grpc/support/histogram.c
Used in:
first bucket is [0, 1 + resolution)
use enough buckets to allow this value
Used in:
Request current stats
Used in:
,if true, the stats will be reset after taking their snapshot.
A block of data, to simply increase gRPC message size.
Used in:
, , , ,DEPRECATED, don't use. To be removed shortly. The type of data in body.
Primary contents of payload.
Used in:
,DEPRECATED, don't use. To be removed shortly. The type of payload that should be returned.
Used in:
, ,Compressable text format.
Parameters of poisson process distribution, which is a good representation of activity coming in from independent identical stationary sources.
Used in:
The rate of arrivals (a.k.a. lambda parameter of the exp distribution).
Used in:
,Configuration for a particular response.
Used in:
Desired payload sizes in responses from the server.
Desired interval between consecutive responses in the response stream in microseconds.
Whether to request the server to compress the response. This field is "nullable" in order to interoperate seamlessly with clients not able to implement the full compression tests by introspecting the call to verify the response's compression status.
Used in:
A single performance scenario: input to qps_json_driver
Used in:
,Human readable name for this scenario
Client configuration
Number of clients to start for the test
Server configuration
Number of servers to start for the test
Warmup period, in seconds
Benchmark time, in seconds
Number of workers to spawn locally (usually zero)
Basic summary that can be computed from ClientStats and ServerStats once the scenario has finished.
Used in:
Total number of operations per second over all clients.
QPS per one server core.
server load based on system_time (0.85 => 85%)
server load based on user_time (0.85 => 85%)
client load based on system_time (0.85 => 85%)
client load based on user_time (0.85 => 85%)
X% latency percentiles (in nanoseconds)
server cpu usage percentage
Number of requests that succeeded/failed
Number of polls called inside completion queue per request
Queries per CPU-sec over all servers or clients
A set of scenarios to be run with qps_json_driver
presence of SecurityParams implies use of TLS
Used in:
,Used in:
,Port on which to listen. Zero means pick unused port.
Only for async server. Number of threads used to serve the requests.
Specify the number of cores to limit server to, if desired
payload config, used in generic server. Note this must NOT be used in proto (non-generic) servers. For proto servers, 'response sizes' must be configured from the 'response_size' field of the 'SimpleRequest' objects in RPC requests.
Specify the cores we should run the server on, if desired
If we use an OTHER_SERVER client_type, this string gives more detail
Number of threads that share each completion queue
Buffer pool size (no buffer pool specified if unset)
Used in:
,wall clock time change in seconds since last reset
change in user time (in seconds) used by the server since last reset
change in server time (in seconds) used by the server process and all threads since last reset
change in total cpu time of the server (data from proc/stat)
change in idle time of the server (data from proc/stat)
Number of polls called inside completion queue
Used in:
used for some language-specific variants
Used in:
Unary request.
Used as request type in: BenchmarkService.StreamingBothWays, BenchmarkService.StreamingCall, BenchmarkService.StreamingFromClient, BenchmarkService.StreamingFromServer, BenchmarkService.UnaryCall, TestService.CacheableUnaryCall, TestService.UnaryCall
DEPRECATED, don't use. To be removed shortly. Desired payload type in the response from the server. If response_type is RANDOM, server randomly chooses one from other formats.
Desired payload size in the response from the server.
Optional input payload sent along with the request.
Whether SimpleResponse should include username.
Whether SimpleResponse should include OAuth scope.
Whether to request the server to compress the response. This field is "nullable" in order to interoperate seamlessly with clients not able to implement the full compression tests by introspecting the call to verify the response's compression status.
Whether server should return a given status
Whether the server should expect this request to be compressed.
Unary response, as configured by the request.
Used as response type in: BenchmarkService.StreamingBothWays, BenchmarkService.StreamingCall, BenchmarkService.StreamingFromClient, BenchmarkService.StreamingFromServer, BenchmarkService.UnaryCall, TestService.CacheableUnaryCall, TestService.UnaryCall
Payload to increase message size.
The user the request came from, for verifying authentication was successful when the client expected it.
OAuth scope.
Server-streaming request.
Used as request type in: TestService.FullDuplexCall, TestService.HalfDuplexCall, TestService.StreamingOutputCall
DEPRECATED, don't use. To be removed shortly. Desired payload type in the response from the server. If response_type is RANDOM, the payload from each response in the stream might be of different types. This is to simulate a mixed type of payload stream.
Configuration for each expected response message.
Optional input payload sent along with the request.
Whether server should return a given status
Server-streaming response, as configured by the request and parameters.
Used as response type in: TestService.FullDuplexCall, TestService.HalfDuplexCall, TestService.StreamingOutputCall
Payload to increase response size.
Used as request type in: WorkerService.QuitWorker
Used as response type in: ReportQpsScenarioService.ReportScenario, WorkerService.QuitWorker
(message has no fields)