GRPC 服务器响应延迟

Question

首先，是否有人对 GRPC 客户端-服务器实现与/sa websocket+protobuf 客户端-服务器实现之间的吞吐量/延迟进行了性能比较？或者至少是类似的东西。

为了达到这个目标，我正在尝试示例 JAVA helloworld grpc 客户端-服务器，并尝试将响应的延迟与类似的 websocket 客户端-服务器进行比较。目前我正在我的本地机器上用客户端和服务器尝试这个。

websocket 客户端-服务器在服务器端有一个简单的 while 循环。对于 grpc 服务器，我注意到它使用异步执行模型。我怀疑它为每个客户端请求创建一个新线程，从而导致额外的处理开销。例如，我测量的 websocket 响应延迟大约为 6-7 毫秒，grpc 示例显示大约 600-700 毫秒的延迟，占 protobuf 开销。

为了对grpc做类似的比较，有没有办法同步运行grpc服务器？我希望能够消除线程创建/调度的开销以及异步处理引入的其他此类内部开销。

我确实理解 grpc 中涉及的 protobuf 开销在我的 websocket 客户端 - 服务器示例中不存在。但是，我可以通过测量 protobuf 处理引入的开销来解释这一点。

另外，如果我不能同步运行 grpc 服务器，我至少可以测量线程调度/异步处理开销吗？

我对 JAVA 比较陌生，所以请原谅我的无知。

Answer 1

Java 中的基准测试很容易出错。您需要为多个级别的 JIT 进行数秒的预热。您还需要时间让堆大小趋于平稳。在简单的一次性基准测试中，由于类加载，很容易看出最后运行的代码最快（与该代码是什么无关）。600 毫秒对于 gRPC 延迟来说是一个非常大的数字；我们看到两台机器之间使用 TLS 的 Google Compute Engine中位延迟约为 300 µs。我希望您没有预热，因此您正在计算 Java 加载 gRPC 所需的时间，并使用带有 gRPC 的解释器测量 Java。

没有同步版本的 gRPC 服务器，即使有，默认情况下它仍然会使用单独的线程运行。grpc-java 使用缓存线程池，因此在初始请求后 gRPC 应该能够重新使用线程来调用服务。

在线程之间跳转的成本通常很低，尽管它会增加尾部延迟。在一些进程内 NOOP 基准测试中，我们看到使用额外线程在 8 微秒内完成 RPC 完成，没有时则是 4 微秒。如果你真的想要，你可以serverBuilder.directExecutor()用来避免线程跳跃。请注意，大多数服务使用该选项会变慢，并且尾部延迟非常差，因为服务处理可能会延迟 I/O。