java - GRPC 服务器响应延迟

Question

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

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

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

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

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

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

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

Answer 1

Java 中的基准测试很容易出错。您需要为多个级别的 JIT 进行许多秒的预热才能启动。您还需要时间让堆大小趋于平稳。在简单的一次性基准测试中，很容易看出最后运行的代码是最快的(与代码无关)，这是由于类加载。 600 毫秒对于 gRPC 延迟来说是一个非常大的数字；我们看到around 300 µs median latency在两台机器之间的谷歌计算引擎上，使用 TLS。我希望你没有预热，所以你正在计算 Java 加载 gRPC 所花费的时间，并使用其解释器和 gRPC 来测量 Java。

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

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