我正在使用 GHZ 在我的一元 gRPC 服务器上运行性能测试，在大约 100K 请求的负载下，初始几千个请求的响应时间很长（大约 1 秒到 1.5 秒）。 经过一些调试，我观察到 gRPC 服务器拦截器结束和调用 gRPC 服务方法之间有大约 500 毫秒的延迟，服务方法结束和调用 SimpleForwardingServerCallListener.onComplete 之间有大约 500 毫秒的延迟。 可能是什么导致了这种延迟，我为 netty 服务器配置了 8 个线程，为 gRPC 取消上下文执行器配置了 8 个线程。
【问题讨论】：
标签： java spring-boot netty grpc grpc-java
已经在 github java-grpc 上发布了同样的问题，下面是线程。 https://github.com/grpc/grpc-java/issues/7372
TL;DR
大量并发用户（num users >> num gRPC worker threads ）意味着系统被超额订阅并且无法处理请求，从而创建待处理的请求积压。即使请求被 gRPC 事件循环线程接受，这也会导致处理请求的延迟。例如。处理单个请求的总时间= 375ms gRPC服务器拦截器（ServerInterceptor.interceptCall）结束和gRPC服务调用之间的时间= 162ms gRPC服务处理请求的时间= 65ms gRPC服务结束和SimpleForwardingServerCallListener.onComplete调用之间的时间= 148 毫秒
382/61=6.2，因此系统超额认购了 6.2 倍。 100/6.2=16，这将更接近它可以处理的最大并发 RPC。
【讨论】：