GRPC服务器响应延迟

Question

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

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

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

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

我明白在我的websocket客户端 - 服务器示例中没有涉及grpc的protobuf开销。但是我可以通过测量protobuf处理引入的开销来解释这个问题。

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

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

Answer 1

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

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

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

Answer 2

  

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

您可以创建同步客户端。通常，异步更快。 （在Scala中测试）您可以简单地使用以非阻塞方式获得的所有资源。我将根据服务器每秒可处理的客户端数量来创建一个测试。您可以限制每个客户端的传入请求，以确保您的服务不会崩溃。对于HTTP 2，异步也更好.HTTP 2提供了多路复用。

对于基准测试，我可以推荐Metrics。您可以通过日志或http端点公开指标。