换盘了、调了配置、升了版本存储到底快没快这个问题靠感觉和dd答不出来。对象存储走 S3 接口要按 HTTP 请求算吞吐、延迟和分位数还得把每轮的原始数据留下来下次才能比。这篇用 warpMinIO 社区的开源 S3 压测工具对着 RustFS 把流程走完整装上、连上被测端点、跑第一轮、把输出读明白、把结果存成可对比的档案。文中所有命令、参数和示例输出都出自 warp 官方 README没有编造的数字README 里的示例数字是在它自己的测试环境跑出来的仅供看懂输出结构换成 RustFS 的数字得自己跑。为什么挑 warp而不是自己写个脚本压自写循环压测通常栽在两件事上一是只算平均数p99 抖动全被平均掉二是跑完不留原始数据两周后想复算只能重跑。warp 把这两件事都替你做了它是 Go 写的单二进制工具release 页直接下各平台的可执行文件每次基准跑完会把每一个请求的明细存成一份 zstd 压缩的 CSV默认文件名形如warp-operation-2026-10-12[143000]-xxxx.csv.zst。事后用warp analyze随时重新分析换个分析参数就能从另一个角度看同一份数据不用重跑。安装两条路。省事的直接从 warp Releases 下载对应平台的二进制有 Go 环境的从源码编README 要求 Go 1.21 以上gitclone https://github.com/minio/warp.gitcdwarpgo build另外有个独立的warp-rdma包支持把 PUT/GET 的负载走 RDMA 直送内存或显存标准二进制不支持--rdma旗标需要时从 release 单独装。日常压 S3 接口用不到它。子命令按操作类型分get、put、delete、list、stat各测一种mixed按比例混跑多种操作multipart和multipart-put测分片上传下载还有versioned、snowball、atomic这类专项。没有叫warp s3的总命令别照着老教程找。把 RustFS 端点和密钥备好注意那口会被清空的桶被测端用 RustFSS3 API 默认监听 9000 端口所以 endpoint 写http://rustfs-host:9000。注意 9001 是控制台端口给人看 Web 界面用的压测别打到这个口。RustFS 是 Apache 2.0 协议、兼容 S3 的分布式对象存储部署与密钥管理见官方文档。warp 的连接参数是--host、--access-key、--secret-keyTLS 加--tls自定义 region 加--region。同样的东西也能走环境变量WARP_HOST、WARP_ACCESS_KEY、WARP_SECRET_KEY、WARP_REGION、WARP_TLS写进脚本比每条命令重复敲干净。README 对密钥权限有明确要求必须能创建、删除、列出桶还要能上传对象只读账号跑不了。最大的一个坑在这里warp 默认操作一个叫warp-benchmark-bucket的桶每轮基准开始前和结束后都会把它整个清空。README 用警告框原话强调了桶里不能放任何数据。所以要么用--bucket指一个专用的空桶要么确认目标桶里没有你舍不得的东西。把生产桶指给 warp等于亲手执行了一次全删。第一跑一条命令先测读最小可用命令就一行warp get--hosthttp://rustfs-host:9000\--access-keyACCESS_KEY--secret-keySECRET_KEY\--duration1mwarp get会先往桶里上传--objects个--obj.size大小的对象这批上传的耗时也会作为 PUT 统计展示然后开始随机下载跑满--duration为止。跑完输出长这样原样引自 README 的 GET 章节注意这是 README 测试环境的示例数字Operation: GET * Average: 94.10 MiB/s, 9866.97 obj/s Throughput, split into 299 x 1s: * Fastest: 99.8MiB/s, 10468.54 obj/s * 50% Median: 94.4MiB/s, 9893.37 obj/s * Slowest: 69.4MiB/s, 7279.03 obj/s三段结构第一行是整轮平均后面是把全程切成 299 个 1 秒段后最快段、中位段、最慢段各是多少。这两组数差距大不大比平均值本身更能说明稳不稳。读性能还有 TTFB首字节时间的统计加--analyze.v会展开成完整的分位数表下一节细说。三个变体按需用。想拿桶里已有的对象当测试集、跳过预上传加--list-existingwarp 会先列出至多--objects个对象再随机下载它们想测部分读Range 请求加--range每次从随机偏移读随机长度S3 网关类应用和断点续传场景对口的正是这条路桶开了版本控制想顺带测版本化读用--versionsn指定每个对象放几个版本。默认情况下 warp 上传的都是随机数据这个设计是有意的避免存储端对可压缩内容做优化测出来的才是裸吞吐。duration、concurrent、obj.size三个旋钮决定你在测什么同一套存储这三个参数不同数字能差出一个数量级所以报数字必须连参数一起报。--duration控制压多久。太短会撞上预热期TCP 爬坡、缓存未热都拉低数字太长浪费时间。一分钟起步正式对比再加长。--concurrent控制并发操作数默认 20。README 专门提醒调并发对性能有影响测延迟的时候尤其明显。想知道吞吐上限把并发往上调到吞吐不再涨为止想知道单请求延迟就压低并发。--obj.size控制对象大小默认值按子命令各不相同。固定大小适合对照测试加--obj.randsize变成随机大小上限还是--obj.size分布按 log2 切README 给了换算平均大小约为--obj.size乘 0.179151想要目标平均大小就乘 5.582 得出该填的最大值。它还接受分桶格式4096:10740,8192:1685,16384:1623表示 0 到 4096 字节这段占权重 10740以此类推用来模拟真实业务的大小分布。还有个--autoterm让 warp 自己判断稳定性它持续把当前数据降采样成 25 个点最后 7 个点落在阈值内就提前收工阈值默认 7.5%--autoterm.pct可改。好处是不用手掐表代价是每轮实际时长不同对比时要用 50% Median不能用 AverageREADME 明确提醒这种场景下不该比均值中位数好得多。单一操作之外mixed子命令按比例混跑四种操作配--get-distrib、--stat-distrib、--put-distrib、--delete-distrib四个旗标调比例设 0 关掉某类最终占比按各值的分数决定。它有个约束put-distrib必须大于等于--delete-distrib不然对象池迟早被删空。想贴近真实业务的读写比用 mixed 比单跑get或put更有说服力代价是结果里 GET、PUT 各算各的吞吐不能简单相加对外报。输出怎么读看 Median、看 TTFB别忘了预热被裁掉了先说一个容易懵的点你跑了 60 秒输出里的分析时长可能只有 59.9 秒甚至更少。别慌这是 warp 故意裁的。README 写明了分析窗口的起止从所有线程都完成第一个请求开始到最后一个线程发起请求为止两头裁掉为的是排除预热和收尾的抖动。看懂这个就不会把时间对不上当成 bug。逐行拆一遍输出Average整轮平均吞吐和对象速率。大对象看 MiB/s小对象和元数据类操作看 obj/sstat这种操作只报 obj/s。50% Median中位 1 秒段的值。两轮结果对比看这个数别看 Average理由上一节说过。Fastest/Slowest最快和最慢的 1 秒段。Slowest 和 Median 差距悬殊通常意味着有卡顿源值得去查。TTFBREADME 的定义分两个方向下载是从请求发出到收到响应第一个字节的时间上传是从请求体最后一个字节发出到收到响应的时间。读场景的响应快慢基本就看它。默认输出只有均值级别的信息加--analyze.v才展开每请求的分位数Avg、50%、90%、99%、Fastest、SlowestTTFB 同样一套还能按主机拆开看多节点集群排查单节点拖后腿就靠这个。--analyze.opGET只看某一类操作--analyze.host只看某一台分析窗口想再裁就加--analyze.skip10s跳过开头 10 秒。分位数里还藏了两个容易被略过的指标First Access 和 Last Access分别是每个对象的首次和末次访问耗时预上传阶段的 PUT 慢、正式阶段的 GET 快从这个切面能看出来。想把切段后的时序数据导出去画图--analyze.out文件.csv会把每段的吞吐、对象数、错误数写成标准 CSV字段表在 README 里。两次跑的结果要能摆在一起比流程得先固定基准数字只在同条件下才有意义。想做到调配置前后的两组数能直接对上流程比工具重要固定版本和参数记下 warp 版本、RustFS 版本、完整命令行。并发、对象大小、时长任何一个变了数字就不该放一起比。归档原始数据每轮的csv.zst文件按默认命名存好这是你的复算凭证想自己命名用--benchdata指定。用warp cmp出对比报告warp cmp 旧文件.csv.zst 新文件.csv.zst输出直接给百分比差值Average、Median、Slowest 各一行参数差异也会列出来。客户端瓶颈要排掉单台客户端打不满服务端时测出来的是客户端的上限。warp 支持多机分布式压测各机器跑warp client默认监听 7761 端口主控端加--warp-clientclient-{1...10}:7761协调发压参数按每个客户端各自生效--concurrent8意味着每台都是 8。散跑的几轮也能事后用warp merge合并但只有时间上真正重叠的数据会被算进去所以各客户端要时钟同步README 建议对齐到 1 秒内最好用--syncstart对齐起跑。还有个对复现特别有用的机制warp 支持把整套参数写进 YAML 配置文件README 在 yml-samples 目录放了每种基准类型的样例用warp run file.yml运行命令行里还能用-var 变量名值往模板里注入变量。把每次基准的 YAML 和产出文件放同一个目录归档半年后别人拿着这份 YAML 就能原样复跑比翻聊天记录找命令行可靠得多。被测端是多节点时--host支持逗号分隔多地址和{1...8}区间展开warp 默认把请求派给在途请求最少的主机想改成轮询用--host-selectroundrobin。至于上线前该测哪几组读场景之前写过一篇《S3对象存储上生产务必做的3组读压测》讲的是测什么这篇讲的是怎么测两篇配合着用。踩坑清单都写在 README 里了桶会被清空再强调一次warp-benchmark-bucket或--bucket指定的桶每轮前后都会被 wipeREADME 警告框原文是should not contain any data。端口别打错RustFS 的 S3 API 在 9000控制台在 9001压测目标永远是前者。预热和抖动分析窗口自动裁掉了预热但如果你判断预热期更长用--analyze.skip再裁重跑几轮取一致的区间比单轮的 Fastest 可信。数字上不去先怀疑客户端单机带宽、CPU、连接数都可能先于存储饱和。分布式模式和warp merge都是为消掉客户端瓶颈准备的。并发是每客户端的分布式压测时总并发是--concurrent乘以客户端数README 原话parameters apply to each client。csv.zst会随规模变大明细是按请求逐条记录的时长和并发加上去文件就跟着变大几轮长压测的产出归档前留意磁盘占用别让它把归档盘塞满。warp 测的是 S3 协议层它评估的是经 HTTP 的 S3 接口表现底层磁盘的块设备性能要用 fio 这类工具单独测两者不能互相替代报数字时别把 S3 压测结果说成磁盘性能。下次动配置前先跑这一轮动作收拢成四步装 warprelease 二进制或 Go 1.21 自编--bucket指个专用空桶一条warp get --duration1m跑基线改配置后同参数再跑一轮warp cmp出差值。原始csv.zst和完整命令行一起归档半年后还能复算。相关入口warp 仓库与 Releases 页各平台二进制README 覆盖全部旗标说明RustFS 文档覆盖部署与密钥配置。