blob: c87557558dd0fc81d2839e92312c0fc817d0f257 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
# 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.
|
