7.3 基准测试：跑分与解读

7.3 基准测试：跑分与解读

本节摘要：基准测试的价值取决于方法的严谨度。本节以开源压测工具 warp 为主线，讲清场景设计（对象大小、并发、读写混合）、预热与多客户端这两个最常被忽略的环节，以及压测报告三类指标的正确读法。

数字只在方法的约束下成立

主线案例的第一份验收报告为什么测出"六成"？事后复盘，那份报告的压测方法有三个硬伤：单台压测客户端（一台客户端的 CPU 与网卡先于集群到达极限）、全部用 64K 小对象（测的是每秒操作数，却拿去对标带宽承诺）、没有预热与多轮次（第一轮读全走冷盘，第二轮全走页缓存，数字差出三成）。方法修完，同样的集群测出了打满万兆的数字。集群没变，变的是尺子——这就是本节反复强调"数字只在方法的约束下成立"的原因。

场景设计：先把业务画像翻译成参数

压测参数表就是把 7.1 的业务画像翻译成数字。四个维度：

对象大小分布：真实业务几乎从不只有一种大小。视频库是大对象为主（10 MB 到 1 GB 级），备份系统是混合分布（大量几十 MB 加少量百 GB），图库是小对象海（百 KB 级）。压测场景按主次配比混合，比如"七成 4 MB 加三成 128 KB"。

并发模型：并发客户端数乘以每客户端并发会话。万兆打满通常需要多客户端——经验上一台万兆客户端压不出超过 3 GB 的聚合读，别用一台机器去验收 25G 的集群。

读写比例：监控类业务写多读少，分发类业务读多写少。分场景单测再混合测，混合比按业务真实流量配。

时长与轮次：单轮不少于十分钟（短测只测到缓存，测不到盘的真实脾气），关键结论至少两轮取稳态。

warp 的典型用法：

# 多客户端分布式压测:客户端们先连同一批参数
warp client --host 客户端机器列表 \
  run --host fleet \
  --obj.size 4m,128k --concurrent 32 \
  --duration 10m --benchdata baseline.zst

# 服务器端对照场景:单独压写
warp run --host fleet --obj.size 64m --concurrent 16 \
  --put --duration 10m
​

图 7-3 一次可信压测的结果轮廓

三类指标的正确读法

吞吐（GB 级每秒）：大对象场景的主指标。读吞吐对照网卡上限减协议开销（TLS 与对象协议有约一成的折损，万兆读到 1.1 GB 级属正常）。

每秒操作数（objects 级每秒）：小对象场景的主指标。它受并发、连接复用、元数据路径影响远大于带宽，与吞吐指标不可互相印证——拿小对象跑出的高吞吐去对标大文件承诺，是验收会上的经典错位。

延迟分布（TTFB 与分位数）：平均延迟会掩盖长尾，P99 与 P999 才是应用体验的真相。压测报告要看分布图而不是均值；对象存储的延迟长尾通常来自纠删集重构、扫描任务与 GC,基线报告里保留分布图，故障时对照能省一半时间。

验收报告的最低标准

一份能签字的压测报告包含五件套：业务画像与参数表的对应关系、客户端规格与数量（证明不是客户端先到极限）、预热与稳态窗口的标注、两轮以上结果的一致性、以及全部原始数据归档。主线案例的验收翻车与翻案，差别只在五件套从无到有。

本节要点回顾

• 尺子先于数字：单客户端、无预热、单一对象大小，三个方法硬伤能把好集群测成残废。
• 场景翻译自画像：大小分布、并发、读写比、时长轮次，四维参数表对着业务写。
• 指标各有领地：吞吐管大对象、每秒操作数管小对象、延迟分布管体验，不可互相对标。
• 报告五件套：参数对应、客户端规格、稳态标注、多轮一致、数据归档，缺一件不签字。

集群又快又稳，最后一章处理规模化之后的归宿：搬上 Kubernetes、装好监控、练熟灾备，再把数据接进业务流水线。

一次报告速读示范

用一组虚拟但贴近真实的数字，示范 7.3 的报告怎么读。场景一：万兆四节点集群，4 MB 对象为主、三成 128 KB 混合，三台客户端并发 32,持续 15 分钟。结果：写吞吐 1.02 GB 级每秒，读吞吐 1.12 GB 级每秒，P99 延迟 85 毫秒。判读：读吞吐约为万兆理论值的九成，扣除协议与 TLS 折损后正常；写吞吐略低于读，来自纠删码编码开销，符合预期；P99 处于健康带。结论：达标。

场景二：同一集群改压 128 KB 纯小对象。结果：每秒 8500 个对象，P99 延迟 45 毫秒。判读：小对象场景的指标是每秒操作数，不能拿去对标场景一的带宽承诺；每秒操作数与并发、元数据路径强相关，若要提升，方向在客户端并发与 7.2 的句柄与连接参数，而不是继续加盘。两个场景合起来的读法要点：先看场景对不对，再看数字好不好，最后才谈优化动作。

验收现场的五问清单

把报告五件套压缩成验收会上的五问，每问得到肯定答案才继续：压测场景与业务画像对应吗？客户端自身到极限了吗（客户端 CPU 与网卡利用率）？预热与稳态窗口标注了吗？两轮结果一致吗（差异不超过半成）？原始数据归档了吗？五问全过，报告才有资格作为验收依据——这一节与全章的最终目的，就是让性能对话从"感觉快"升级为"数字可签"。

压测环境的隔离纪律

还有一个方法论层面的坑要单独拎出来：压测环境与生产环境的隔离。压测请求与业务请求共用一套负载均衡时，压测流量会挤占业务流量的连接队列与带宽——生产环境的延迟尖刺未必来自集群，可能来自压测的邻居。规范做法是为压测开独立的入口（单独的负载均衡实例或直连节点的隔离端口），并在压测期间在监控上把业务流量与压测流量分组观察。同理，压测使用的桶要用独立前缀，压完即清——7.3 的所有严谨，最终都体现为"测出来的数字只含一个变量"的洁癖。

报告之外的最后一件事是沟通。验收会上拿着报告的一方与看着承诺表的一方，经常在各说各话：技术方讲吞吐曲线，业务方只关心"晚上八点卡不卡"。把压测指标翻译回业务语言是工程师的收尾责任——"读吞吐 1.1 GB 级，支撑两万人同时拉流不卡顿"比任何曲线图都更能让会议收敛。数字是工程师的语言，场景是决策者的语言，好的验收报告两者都要有。