GRPC服务器响应延迟

Question

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

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

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

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

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

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

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

Answer 1

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

您可以创建一个同步客户端。一般来说，异步的速度要快得多。（在Scala中测试）您可以简单地以非阻塞方式使用所有资源。我将创建一个测试，测试服务器每秒可以处理多少个客户端的请求。您可以限制每个客户端的传入请求，以确保您的服务不会崩溃。异步也更适合HTTP 2。HTTP 2提供多路复用。

对于基准测试，我可以推荐指标。您可以通过日志或httpendpoint公开度量。

Answer 2

Java中的基准测试很容易出错。你需要做几秒钟的热身，才能让多层次的准时制发挥作用。您还需要时间来稳定堆大小。在一个简单的一次性基准测试中，由于类加载，很容易看到最后运行的代码是最快的（与代码无关）。600毫秒对于gRPC延迟来说是一个非常大的数字；我们在Google Compute Engine上看到两台机器之间的平均延迟约为300µs，使用TLS。我希望您没有热身，所以您正在计算Java加载gRPC所需的时间，并使用gRPC的解释器测量Java。

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

在线程之间跳转的成本通常很低，尽管它会增加尾部延迟。在一些进程内NOOP基准测试中，我们看到使用额外线程在8µs内完成RPC，而不使用额外线程在4µs内完成RPC。如果你真的想要，你可以使用serverBuilder。directExecutor（）以避免线程跳转。请注意，由于服务处理可能会延迟I/O，大多数服务使用该选项会变得更慢，并且尾部延迟非常差。