我正在使用 GHZ 在我的一元 gRPC 服务器上运行性能测试，在大约 10 万个请求的负载下，最初几千个请求的响应时间很长(大约 1 秒到 1.5 秒)。 经过一些调试后，我观察到在 gRPC 服务器拦截器结束和调用 gRPC 服务方法之间有大约 500 毫秒的延迟，在服务方法结束和调用 SimpleForwardingServerCallListener.onComplete 之间有大约 500 毫秒的延迟。 是什么导致了这种延迟，我为 netty 服务器配置了 8 个线程，为 gRPC 取消上下文执行器配置了 8 个线程。
最佳答案
在 github java-grpc 上发布了同样的问题，下面是线程。 https://github.com/grpc/grpc-java/issues/7372
长话短说
大量并发用户(num users >> num gRPC worker threads )意味着系统超额订阅，无法处理请求，从而产生待处理请求的积压。这会导致延迟处理请求，即使请求已被 gRPC 事件循环线程接受。例如。处理单个请求的总时间 = 375 毫秒 gRPC 服务器拦截器(ServerInterceptor.interceptCall)结束和调用 gRPC 服务之间的时间 = 162 毫秒 gRPC 服务处理请求的时间 = 65 毫秒 gRPC 服务结束和调用 SimpleForwardingServerCallListener.onComplete 之间的时间= 148 毫秒
382/61=6.2，因此系统超额认购了 6.2 倍。 100/6.2=16 这将更接近它可以处理的最大并发 RPC。
关于java - gRPC-java 服务器在负载下处理请求和发送响应的延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63636258/