gRPC 中高吞吐量低延迟一元调用指南答案

【问题标题】：Guidelines for high-throughput low-latency unary calls in gRPCgRPC 中高吞吐量低延迟一元调用指南
【发布时间】：2019-10-17 00:45:04
【问题描述】：

我正在寻找指南以最大限度地提高吞吐量并最大限度地减少 gRPC 一元调用的延迟。我需要达到大约 20,000 QPS，每个

【问题讨论】：

gRPC 的 benchmarking suite 显示使用 TLS 的 8 核 GCE VM 的延迟为 195µs（对于单个 RPC）和 245k QPS。有很多因素会影响结果，但最基本的是基准测试的类型、预热量和网络。您的数字与预期相差甚远，我通常认为这是因为没有预热期让 JIT 有时间优化代码，但这是在黑暗中拍摄。
感谢@EricAnderson。我现在在 AWS r4.2xlarge 实例上同时运行客户端/服务器。我得到了更好的吞吐量 - 50K（预热后）和预期的低延迟。客户端是单线程的。两个客户端/服务器实例的 CPU 为 ~200%（使用了两个线程）。我怎样才能挤出更多的性能？

标签： grpc grpc-java

【解决方案1】：

如果您使用的是 grpc-java 1.21 或更高版本以及grpc-netty-shaded，您应该已经在使用 Netty Epoll 传输。如果您使用的是grpc-netty，请在io.netty:netty-transport-native-epoll 上添加运行时依赖项（可以通过查看grpc-netty 的pom.xml 或version table in SECURITY.md 找到正确的版本）。

回调的默认执行器是“缓存线程池”。如果您不阻塞（或知道阻塞的限制），则指定固定大小的线程池可以提高性能。你可以试试Executors.newFixedThreadPool 和ForkJoinPool；我们已经看到“最佳”选择因工作量而异。您可以通过ServerBuilder.executor() 和ManagedChannelBuilder.executor() 指定自己的执行者。

如果您具有高吞吐量（使用 TLS 的每个客户端约 Gbps+；如果使用纯文本则更高），则使用多个通道可以通过使用多个 TCP 连接来提高性能。每个 TCP 连接都固定到一个线程，因此拥有更多 TCP 连接允许使用更多线程。您可以创建多个频道，然后对它们进行循环；为每个 RPC 选择不同的。请注意，您可以轻松地实现Channel 接口以“隐藏”应用程序其余部分的复杂性。这看起来会特别为您提供很大的收益，但我把它放在最后，因为它通常没有必要。

【讨论】：

您可以考虑以this ChannelPool 为例。请注意，它比严格必要的要长，因为它实现了 ManagedChannel 而不是 Channel。