基于gRPC协议的内部Composer镜像管理平台性能压测实战

开头先亮结论：用 ghz 压测 Composer 镜像平台的 gRPC 接口，必须直连后端 gRPC 服务端口（比如 localhost:50051），绕开 PHP 自动加载和 HTTP 网关层。否则，你测出来的根本不是镜像服务的真实性能，而是 Nginx 的转发延迟，或者是 Composer 客户端自身的解析开销。

为什么不能走 curl 或 Webman API 网关压测 gRPC？

gRPC 是基于 HTTP/2 的二进制协议。curl 默认走 HTTP/1.1，即便加了 --http2 参数，也拿不到正确响应——通常会返回 426 Upgrade Required 或干脆空响应。Webman 本身也不支持原生 gRPC 流量透传，得靠 Nginx 的 grpc_pass 转发。如果压测链路是 ghz → Webman → Nginx → gRPC Server，那实际测的就是 Nginx 的 grpc_pass 性能，外加 TLS 握手和 HTTP/2 帧解包的消耗，根本不是镜像服务自身的吞吐能力。

不少团队踩过这些坑，典型报错如下：

• 执行 ghz -c 10 -n 100 --proto=mirror.proto --call mirror.MirrorService.GetPackage localhost:8080，结果报错 rpc error: code = Una vailable desc = connection closed before server preface received
• 响应时间波动极大，从 20ms 到 2s 都有，而且 ghz 统计里充斥着 connection refused 或 deadline exceeded
• 服务端日志显示连接根本没进入业务逻辑，卡在 TLS 握手或 HTTP/2 设置帧协商阶段

正确的做法是：

• 确认 gRPC 服务监听地址是 0.0.0.0:50051，而不是 127.0.0.1:50051，尤其在 Docker 容器里这点容易出问题
• 压测命令直连该端口：ghz -c 50 -n 5000 --proto=mirror.proto --call mirror.MirrorService.GetPackage localhost:50051
• 禁用 Nginx 和 Webman 等中间层，避免干扰

ghz 压测时，proto 文件与参数必须匹配服务端定义

ghz 依赖 .proto 文件来生成请求 payload 结构。如果镜像平台用了嵌套 message、optional 字段，或是自定义 option（比如 (validate.rules).message.required = true），而 ghz 的 -d 参数传入的 JSON 不符合这些规则，服务端会直接返回 INVALID_ARGUMENT，导致压测失败率虚高。

几个常见场景：

• 服务端定义了 message GetPackageRequest { string name = 1 [ (validate.rules).string.min_len = 1 ]; }，但 -d '{"name":""}' 触发了校验失败
• proto 里使用了 google.api.field_beha vior 扩展，但 ghz 不识别，JSON 里漏传了必填字段
• message 字段编号（tag）与实际 PHP/Go 服务端生成的 stub 不一致，导致二进制解析错位

实操建议：

• 用 -D 指向一个合法的 JSON 文件，内容可以从真实客户端调用中抓包提取——比如用 Wireshark 过滤 HTTP/2 DATA 帧，或者从服务端日志 dump 原始请求数据
• 先跑一次单请求验证：ghz --proto=mirror.proto --call mirror.MirrorService.GetPackage -d '{"name":"monolog/monolog"}' localhost:50051，确保返回 200 OK 再提高并发
• 如果服务端启用了 gRPC-Gateway，可以先通过它生成的 REST 接口调试 JSON 结构，再反推 gRPC 请求体

PHP 客户端复用 channel 是压测稳定的关键

如果 Composer 镜像平台提供了 PHP SDK，它的 gRPC 客户端必须复用 GrpcChannel 实例。每次 new Channel 都会新建 TCP 连接、做 TLS 握手、交换 HTTP/2 settings 帧，QPS 上不去不说，还容易触发 too many open files 错误。

看个对比：

❌ 错误做法：每请求新建 channel
for ($i = 0; $i < 100; $i++) {
    $channel = new GrpcChannel('localhost:50051', [
        'credentials' => GrpcChannelCredentials::createInsecure(),
    ]);
    $client = new MirrorServiceClient($channel);
    list($response, $status) = $client->GetPackage($request)->wait();
    $channel->close();
}

✅ 正确做法：全局复用 channel
$channel = new GrpcChannel('localhost:50051', [
    'credentials' => GrpcChannelCredentials::createInsecure(),
    'grpc.keepalive_time_ms' => 30000,
]);
$client = new MirrorServiceClient($channel);
for ($i = 0; $i < 100; $i++) {
    list($response, $status) = $client->GetPackage($request)->wait();
}
$channel->close();

需要注意几个关键点：

• grpc.keepalive_time_ms 必须显式设置，防止连接因空闲超时被断开
• 不要在循环内调用 $channel->close()，否则后续请求会报 Channel is closed
• Docker 环境下，localhost 在容器内不指向宿主机，应该改用宿主机 IP 或 Docker network 别名

真实压测中容易被忽略的资源瓶颈

镜像平台本质上是 I/O 密集型服务：高频读取本地文件系统（比如 /var/www/mirror/packagist/ 下的 ZIP 包）、计算 SHA256、压缩响应流。CPU 往往不是瓶颈，但下面三点常被忽视：

• Linux 文件句柄限制：ghz -c 200 并发时，服务端可能打开上千个文件描述符，需要提前执行 ulimit -n 65536 并检查 /proc/sys/fs/file-max
• 磁盘 IO 队列深度：机械盘在随机小文件读场景下极易成为瓶颈，压测前可以用 iostat -x 1 观察 %util 是否持续超过 90%
• gRPC 消息大小限制：服务端默认最大接收 4MB，如果镜像包元数据或 ZIP 流过大，需要在服务端启动时显式配置 max_receive_message_length（Go）或 grpc.max_message_length（PHP 扩展）

最后一句提醒：压测报告里的 P99 延迟，往往不是网络或 CPU 决定的，而是某次 stat() 系统调用卡在 ext4 日志提交上，或者 ZIP 解压时触发了 PHP 的内存回收暂停。别只盯着 ghz 的输出，得看看 strace -p $(pidof your-server) -e trace=stat,open,read。