结论：用ghz压测Composer镜像平台的gRPC接口必须直连后端gRPC服务端口（如localhost:50051），绕开PHP自动加载和HTTP网关层，否则测的是Nginx转发延迟或Composer客户端解析开销，而非镜像服务真实性能。
直接说结论：用 ghz 压测 Composer 镜像平台的 gRPC 接口，必须绕开 PHP 自动加载和 HTTP 网关层，直连后端 gRPC 服务端口；否则测出来的不是镜像服务性能，而是 Webman/Nginx 的转发延迟或 Composer 客户端解析开销。
为什么不能用 curl 或 Webman API 网关做 gRPC 压测
gRPC 是基于 HTTP/2 的二进制协议，curl 默认走 HTTP/1.1，即使加 --http2 也拿不到正确响应——会返回 426 Upgrade Required 或空响应。Webman 本身不支持原生 gRPC 流量透传，必须靠 Nginx 的 grpc_pass 转发；而压测时若经过 Webman → Nginx → gRPC Server 这条链路，ghz 实际测的是 Nginx 的 grpc_pass 性能 + TLS 握手 + HTTP/2 帧解包，不是镜像服务本身的吞吐能力。
常见错误现象：
- 执行
ghz -c 10 -n 100 --proto=mirror.proto --call mirror.MirrorService.GetPackage localhost:8080报错rpc error: code = Unavailable 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_behavior扩展，但ghz不识别，JSON 里漏传必填字段 - message 字段编号（tag）与实际 PHP/Go 服务端生成的 stub 不一致，造成二进制解析错位
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
-D指向一个合法 JSON 文件，内容从真实客户端调用中抓包提取（例如用 Wireshark 过滤 HTTP/2 DATA 帧，或服务端日志 dump raw request） - 先跑一次单请求验证：
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 客户端必须复用 Grpc\Channel 实例。每次 new Channel 都会新建 TCP 连接 + TLS 握手 + HTTP/2 settings 帧交换，QPS 上不去还容易触发 too many open files 错误。
对比示例：
❌ 错误：每请求新建 channel
for ($i = 0; $i Grpc\ChannelCredentials::createInsecure(),
]);
$client = new MirrorServiceClient($channel);
list($response, $status) = $client->GetPackage($request)->wait();
$channel->close();
}
✅ 正确：全局复用 channel
$channel = new Grpc\Channel('localhost:50051', [
'credentials' => Grpc\ChannelCredentials::createInsecure(),
'grpc.keepalive_time_ms' => 30000,
]);
$client = new MirrorServiceClient($channel);
for ($i = 0; $i 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。
