aboutsummaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorGravatar Craig Tiller <ctiller@google.com>2017-01-06 11:16:32 -0800
committerGravatar GitHub <noreply@github.com>2017-01-06 11:16:32 -0800
commitaeddd38b0eeeb49a2a65f0d1fa8211562196228c (patch)
tree08b85f660ffb9baab6dc6a1a6d16d339bfe7b6f6
parent13ac3031aaf630956da68d6debe246c62922224d (diff)
parente61b7d7b77f87442fc2fb63738b3e9a60a189887 (diff)
Merge pull request #9272 from ctiller/perfnotes
Start some performance notes
-rw-r--r--doc/cpp/perf_notes.md29
1 files changed, 29 insertions, 0 deletions
diff --git a/doc/cpp/perf_notes.md b/doc/cpp/perf_notes.md
new file mode 100644
index 0000000000..805ead3638
--- /dev/null
+++ b/doc/cpp/perf_notes.md
@@ -0,0 +1,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:
+
+```c++
+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.