首页 > 解决方案 > 具有大负载的 gRPC 延迟和吞吐量

问题描述

我有一个简单的 spring gRPC 应用程序,它有一个虚拟端点,但返回一个空消息:

原型:

message Map {
    map<string, string> value = 1;
}

service GreetingService {
    rpc GreetMap(Map) returns (google.protobuf.Empty) {}
}

执行:

@Override
public void greetMap(Map request, StreamObserver<Empty> responseObserver) {
    responseObserver.onNext(Empty.getDefaultInstance());
    responseObserver.onCompleted();
}

我正在尝试加载测试这个端点。我正在使用一个名为ghz的工具。我已经生成了一个大的原始消息(327Kb),我正在本地主机上运行这个负载测试(因此没有网络延迟),并发设置为 20 的 200 个请求。

ghz --proto=service.proto -i path/to/imports/ --binary-file=output.bin --call=package.GreetingService/GreetMap --concurrency=20 --total=200 localhost:6565

我的结果令人困惑:

Summary:
  Count:    200
  Total:    543.25 ms
  Slowest:  91.21 ms
  Fastest:  2.41 ms
  Average:  25.47 ms
  Requests/sec: 368.16

Response time histogram:
  2.412 [1] |∎
  11.292 [61]   |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  20.171 [32]   |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  29.051 [26]   |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  37.931 [39]   |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  46.810 [16]   |∎∎∎∎∎∎∎∎∎∎
  55.690 [12]   |∎∎∎∎∎∎∎∎
  64.570 [6]    |∎∎∎∎
  73.449 [2]    |∎
  82.329 [4]    |∎∎∎
  91.209 [1]    |∎

Latency distribution:
  10 % in 5.78 ms
  25 % in 9.93 ms
  50 % in 21.44 ms
  75 % in 36.80 ms
  90 % in 49.21 ms
  95 % in 61.35 ms
  99 % in 79.48 ms

Status code distribution:
  [OK]   200 responses

如我们所见,95%% 的延迟超过 50ms,吞吐量为 368.16 RPS。如果我使用小负载(6B)运行相同的测试,结果将完全不同:

Summary:
  Count:    200
  Total:    30.96 ms
  Slowest:  14.86 ms
  Fastest:  0.35 ms
  Average:  2.90 ms
  Requests/sec: 6460.92

Response time histogram:
  0.354 [1] |
  1.805 [155]   |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  3.256 [4] |∎
  4.706 [20]    |∎∎∎∎∎
  6.157 [0] |
  7.608 [0] |
  9.059 [0] |
  10.509 [0]    |
  11.960 [0]    |
  13.411 [0]    |
  14.862 [20]   |∎∎∎∎∎

Latency distribution:
  10 % in 0.96 ms
  25 % in 1.25 ms
  50 % in 1.49 ms
  75 % in 1.70 ms
  90 % in 13.43 ms
  95 % in 14.51 ms
  99 % in 14.81 ms

Status code distribution:
  [OK]   200 responses

吞吐量提高了约 20 倍(6460.92 RPS),99%% 的延迟约为 15ms。

我唯一能找到的与 gRPC 和有效负载大小有关的是 gRPC-Go 以及描述为 5 毫秒内的 1MB 大小的消息没有网络延迟的延迟。

那么对于 gRPC 来说,处理一个大的有效载荷是一个问题,还是可以对其进行微调以获得更好的性能?

UPD 所以我尝试在负载测试期间分析应用程序,结果并不乐观。大部分 CPU 时间用于消息解析。当然,我不是这方面的专家,但感觉不是可以优化的东西。会很高兴错了 在此处输入图像描述

标签: javaperformancegrpclatencygrpc-java

解决方案


推荐阅读