|
|
|
|
# C++ Performance Notes
|
|
|
|
|
|
|
|
|
|
## Streaming write buffering
|
|
|
|
|
|
|
|
|
|
Generally, each write operation (Write(), WritesDone()) implies a syscall.
|
|
|
|
|
gRPC will try to batch together separate write operations from different
|
|
|
|
|
threads, but currently cannot automatically infer batching in a single stream.
|
|
|
|
|
|
|
|
|
|
If message k+1 in a stream does not rely on responses from message k, it's
|
|
|
|
|
possible to enable write batching by passing a WriteOptions argument to Write
|
|
|
|
|
with the buffer_hint set:
|
|
|
|
|
|
|
|
|
|
~~~{.cpp}
|
|
|
|
|
stream_writer->Write(message, WriteOptions().set_buffer_hint());
|
|
|
|
|
~~~
|
|
|
|
|
|
|
|
|
|
The write will be buffered until one of the following is true:
|
|
|
|
|
- the per-stream buffer is filled (controllable with the channel argument
|
|
|
|
|
GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE) - this prevents infinite buffering leading
|
|
|
|
|
to OOM
|
|
|
|
|
- a subsequent Write without buffer_hint set is posted
|
|
|
|
|
- the call is finished for writing (WritesDone() called on the client,
|
|
|
|
|
or Finish() called on an async server stream, or the service handler returns
|
|
|
|
|
for a sync server stream)
|
|
|
|
|
|
|
|
|
|
## Completion Queues and Threading in the Async API
|
|
|
|
|
|
|
|
|
|
Right now, the best performance trade-off is having numcpu's threads and one
|
|
|
|
|
completion queue per thread.
|
