压测:单连接与多连接的吞吐曲线

连接数

实测 · 本机执行输出

   1 条连接:   90934 请求/秒;p50 661 µs、p99 1436 µs;错误 0
   2 条连接:  113914 请求/秒;p50 498 µs、p99 1376 µs;错误 0
   4 条连接:  118308 请求/秒;p50 431 µs、p99 1629 µs;错误 0
   8 条连接:  111613 请求/秒;p50 415 µs、p99 2036 µs;错误 0
  16 条连接:  106106 请求/秒;p50 426 µs、p99 2190 µs;错误 0

小消息时,多开几条连接能多榨出约三成吞吐,到顶之后再加连接没有收益,p99 反而变差。

大消息

实测 · 本机执行输出

   1 条连接:   21902 请求/秒(1369 MiB/秒 请求方向);p50 2869 µs、p99 5000 µs;错误 0
   2 条连接:   25793 请求/秒(1612 MiB/秒 请求方向);p50 2359 µs、p99 5259 µs;错误 0
   4 条连接:   28625 请求/秒(1789 MiB/秒 请求方向);p50 1893 µs、p99 7311 µs;错误 0
   8 条连接:   27667 请求/秒(1729 MiB/秒 请求方向);p50 1700 µs、p99 11008 µs;错误 0
  16 条连接:   28424 请求/秒(1776 MiB/秒 请求方向);p50 1780 µs、p99 8472 µs;错误 0

64 KiB 消息一条连接就接近上限,瓶颈在拷贝和内存带宽。

并发

实测 · 本机执行输出

    1 个并发调用者:   12421 请求/秒;p50 79 µs、p99 114 µs;错误 0
    4 个并发调用者:   32715 请求/秒;p50 118 µs、p99 280 µs;错误 0
   16 个并发调用者:   66541 请求/秒;p50 226 µs、p99 561 µs;错误 0
   64 个并发调用者:   92493 请求/秒;p50 650 µs、p99 1374 µs;错误 0
  256 个并发调用者:  122073 请求/秒;p50 2090 µs、p99 3351 µs;错误 0

在一条连接上,并发越高吞吐越大,但延迟也越高。吞吐靠排队换来,不能只看吞吐。

流式

实测 · 本机执行输出

  Unary:   12059 次/秒;p50 79 µs、p99 169 µs
  Bidi 流:   15634 次/秒;p50 62 µs、p99 95 µs

无并发的往返里,同一个流上来回比每次 Unary 快一些,因为省去了每个调用的建流和结束开销。

分步演示

压测

本步的对象

本文用到的工具与边界

本机 macOS 27 arm64 / Go 1.27.1 / grpc-go v1.84.0 / protobuf-go v1.36.12 / golang.org/x/net v0.57.0 / protoc 36.2(Homebrew);服务端和客户端都是本机起的 Go 进程(127.0.0.1,端口 9800 以上,不访问任何外部服务);需要看线上字节时用我自己写的 TCP 抓包代理加 golang.org/x/net/http2 的 Framer 解析 HTTP/2 帧;计时用 time.Now 或 perf_counter,数字每次运行会有小幅抖动。服务端是另一个进程(同一台机器),客户端用 64 个、1~256 个 goroutine 连续调用;每档只跑 2 秒、一次;本机有 10 个逻辑 CPU,并且机器上还有别的应用在运行,所以数字有噪声(10% 以内的差别不要当真);回环网络,没有真实网络的延迟、丢包和中间设备
没有验证:多次重复的方差;更多 CPU 或多台机器;TLS 开启时的吞吐;压缩;不同 GOMAXPROCS;服务端 handler 有真实工作(数据库、下游调用)时的曲线;“流式更快是因为省了建流和结束”只是推断,没有分解验证;其它语言的客户端;HTTP/1.1 JSON 对比见第 37 篇

下一篇 · GRPC 37

与 HTTP/1.1 JSON 的对比:同一接口的延迟和字节数