问题描述
我正在使用GHZ在我的一元gRPC服务器上运行性能测试，在大约100K请求的负载下，最初几千个请求的响应时间很高（大约1s至1.5s）。 经过一些调试后，我观察到的是，在gRPC服务器拦截器结束与调用gRPC服务方法之间存在大约500ms的延迟，在服务终止方法与调用SimpleForwardingServerCallListener.onComplete之间存在大约500ms的延迟。 造成此延迟的原因是，我为Netty服务器配置了8个线程，为gRPC取消上下文执行程序配置了8个线程。
解决方法
已经在github java-grpc上发布了相同的问题，下面是线程。 https://github.com/grpc/grpc-java/issues/7372
TL; DR
大量并发用户（num个用户>> num gRPC工作线程）将意味着系统被超额预订并且无法处理请求，从而创建了待处理请求的积压。即使gRPC事件循环线程接受了请求，这也会导致处理请求的延迟。例如。处理单个请求的总时间= 375 ms从gRPC服务器拦截器（ServerInterceptor.interceptCall）结束到调用gRPC服务的时间= 162ms通过gRPC服务处理请求的时间= 65ms从gRPC服务结束到调用SimpleForwardingServerCallListener.onComplete的时间= 148ms
382/61 = 6.2，因此系统超额预订了6.2倍。 100 / 6.2 = 16，它将接近它可以处理的最大并发RPC。