我正在使用GHZ在我的一元gRPC服务器上运行性能测试，在大约100K请求的负载下，最初几千个请求的响应时间很长(大约1秒到1.5s(。经过一些调试，我观察到gRPC服务器拦截器的结束和gRPC服务方法的调用之间有大约500毫秒的延迟，服务方法的结束和SimpleForwardingServerCallListener.onComplete的调用之间大约有500毫秒的延迟。造成这种延迟的原因是，我为netty服务器配置了8个线程，为gRPC取消上下文执行器配置了8条线程。
在github java grpc上发布了同样的问题，下面是线程。https://github.com/grpc/grpc-java/issues/7372
TL；博士
大量并发用户(num个用户>>num个gRPC工作线程(意味着系统订阅过多，无法处理请求，从而造成待处理的请求积压。即使gRPC事件循环线程接受了请求，这也会导致处理请求的延迟。例如处理单个请求的总时间=375ms gRPC服务器拦截器(ServerInterceptor.enterceptCall(结束与调用gRPC服务之间的时间=162ms gRPC服务处理请求的时间=65ms gRPC服务结束与调用SimpleForwardingServerCallListener之间的时间.onComplete=148ms
382/61=6.2，因此系统超额认购了6.2x。100/6.2＝16，这将更接近于它可以处理的最大并发RPC。