网站一到促销活动或流量高峰就变慢，很多站长的第一反应是升级配置，但往往说不清瓶颈到底出在带宽还是应用本身，钱花了问题却依旧。这篇文章教你如何用 iperf3 与 wrk 这两款开源工具完成一次完整的带宽压测，把服务器的网络吞吐能力和网站实际承载量变成看得见的数据，帮助你用证据而不是猜测来决定要不要升级。
我们经常遇到这样的场景：监控面板上 CPU 和内存都很空闲，用户却反馈页面要 5 秒以上才能打开。这种情况多半是带宽（服务器与外界之间的网络传输能力，通常以 Mbps 计量）被打满，或者并发连接数超出了服务器的处理能力。不做压测，就只能靠反复更换配置碰运气，每一次试错都是真金白银。压测的价值在于，它把”多少用户会拖垮我的网站”这个模糊问题变成一组可复现的数字，让你后续选多大的带宽、什么样的主机方案都有据可依。
两个工具各管一段：先测管道，再测业务
带宽压测常见的误区是拿一个工具测到底。实际上 iperf3 和 wrk 的分工完全不同：iperf3 负责测”管道有多粗”，也就是服务器网卡与外网之间的裸吞吐上限；wrk 负责测”管道里能跑多少业务”，也就是在真实 HTTP 请求下网站还能扛住多少并发。先摸清管道上限，再测业务承载，数据才有解读的基准。
两张图能说明这个分工：iperf3 只关心一台服务器和一台测试机之间的数据搬运速度，wrk 则要经过完整的应用栈。如果你的目标是”评估网站承载量”，两者缺一不可——只测 iperf3 会高估实际承载，只测 wrk 又分不清慢在带宽还是慢在代码。
第一步：用 iperf3 摸清带宽上限
必须在服务器和一台外部测试机（比如你本地的一台 VPS（虚拟专用服务器））上各装一份。下面的命令以 Ubuntu/Debian 云服务器（基于虚拟化技术打造的在线主机）为例：
# 服务器端安装并启动
sudo apt install iperf3 -y
iperf3 -s
# 测试机端发起压测（把 203.0.113.10 换成你的服务器 IP）
iperf3 -c 203.0.113.10 -t 30 -P 4这里的 -t 30 表示测试持续 30 秒，-P 4 表示开 4 条并行连接。测试结束后重点看两行数据：sender 端的 sender 吞吐和 receiver 端的 receiver 吞吐。假设你购买的是 100Mbps 带宽，实测 receiver 稳定在 94-97Mbps 就属于正常损耗；如果只有 60Mbps，要么是机房线路问题，要么是运营商限速，这时升级 CPU 完全是无用功。
两个实战细节值得注意。第一，测之前先确认服务商是否按流量计费：一次 30 秒的满速测试大约消耗 350MB 流量，按量计费的机器要多加小心。第二，国内访问海外服务器时，晚高峰（20:00-23:00）和国际线路拥塞会让实测值比凌晨低 30% 以上，所以建议在不同时段各测一轮，取最差值作为容量规划的基准，而不是取最好值。
第二步：用 wrk 压出真实承载量
iperf3 的结果只是”理论上限”，网站实际能服务多少用户，要靠 wrk 在真实页面上压出来。wrk 的安装比 iperf3 稍麻烦一点，需要编译：
sudo apt install build-essential libssl-dev git -y
git clone https://github.com/wg/wrk.git
cd wrk && make
sudo cp wrk /usr/local/bin/压测命令本身很简单，下面这条表示用 4 个线程、200 个并发连接，持续压测 60 秒：
wrk -t4 -c200 -d60s --latency https://你的域名/怎么读结果？我们以一次实际测试为例：一台 2 核 4G 的云服务器，首页压缩后约 120KB，带宽 50Mbps。压到 -c100 时，wrk 报告每秒处理 52 个请求（RPS），平均延迟 380ms，一切正常；升到 -c200 后，RPS 反而跌到 41，延迟飙到 2.1 秒。这个拐点就是这台机器的真实承载边界——50Mbps 带宽 ÷ 120KB 页面 ≈ 每秒最多 52 次完整页面传输，与实测完全吻合。这就是带宽压测的核心算法：带宽上限除以页面平均大小，就是理论上的页面服务上限，wrk 用来验证这个理论值是否成立。
压测时务必盯住两个红线：一是服务器端用 nethogs 或 iftop 观察实时流量，确认网卡是否先于 CPU 打满；二是延迟分布，wrk 输出中 99% 分位延迟（即最慢的 1% 请求）如果超过 3 秒，说明已有大量用户体验崩坏，即使平均值好看也不能算通过。测完之后对比两侧数据：网卡流量远低于 iperf3 上限而延迟已经爆炸，瓶颈在应用层；网卡流量顶到上限，瓶颈才真正在带宽。
一张表定结论：压测数据怎么指导选型
两组数据都拿到后，把结果放进同一张对照表里，结论往往自己就浮出来了：
- iperf3 实测 ≥ 套餐带宽 90%，且 wrk 拐点前的延迟 < 500ms：带宽达标，无需升级，继续观察应用层
- iperf3 实测 < 套餐带宽 70%：先找服务商核查线路，而不是先升级配置
- wrk 拐点 RPS × 页面大小 ≥ 带宽上限的 85%：瓶颈确认在带宽，升级带宽收益立竿见影
- 拐点时网卡流量只有上限一半：瓶颈在 CPU 或应用代码，加带宽是浪费钱
举一个我们处理过的真实案例：一家外贸站的 WordPress 商城在黑五前两周做压测，iperf3 实测 96Mbps（套餐 100M），wrk 在 -c150 时出现拐点，RPS 41、网卡流量 44Mbps。按上述口径判断属于”瓶颈在带宽”，他们在活动前把带宽临时提到 200M，黑五当天峰值流量 176Mbps、页面平均打开时间 1.4 秒，没有触发任何超时告警。反过来，另一家客户 CPU 长期 90% 以上还坚持先升带宽，结果高峰期照样卡顿，白白多付了一个月带宽费——这正是先压测、后升级的意义。
需要提醒的是，压测数据和真实流量之间永远有误差：真实用户有浏览间隔、有 CDN（内容分发网络，把静态资源缓存到离用户更近的节点）分流静态请求，所以压测拐点 RPS 并不能直接乘以 86400 秒换算成”日承载用户数”。更稳妥的做法是拿近期一天的真实访问日志，统计出每秒峰值请求数，再和压测拐点对比，只要真实峰值不超过拐点的 60%，就是安全区间。
压测不是一次性的：把检查变成例行运维
带宽承载能力会随业务演进悄悄变化——首页新增了一个 3MB 的轮播图，页面平均体积涨了 40%，原来的承载结论就作废了。所以建议把带宽压测纳入三个固定时机：大促活动前两周、站点大改版上线前、以及每次更换主机或升级配置后的验收环节。每次压测后把 iperf3 吞吐、wrk 拐点 RPS、99% 分位延迟记录成一份简单的基线档案，和上次数据对比，退化超过 15% 就值得深挖原因。
如果你在整理基线时发现瓶颈出在静态资源占比过高，可以先阅读我们整理过的网站性能优化方法，把图片压缩和缓存策略做扎实，往往不升级带宽也能把拐点抬高一大截。日常运维层面，服务器巡检和基线管理可以参考这篇服务器配置与维护指南，把压测、监控、日志分析串成固定流程。
选型层面，如果你的压测结论是”带宽确实是瓶颈”，Hostease 独立服务器方案提供 100Mbps 起步的大带宽，适合流量峰值明显的电商与外贸站点；如果只是偶尔的流量毛刺，Hostease VPS 的弹性升级通常更划算。建议的做法是：先用本文方法测出拐点，再拿自己的峰值数据去和方案参数逐项对照，而不是直接按”别人家用什么我配什么”来下单。
总结一下完整路径：iperf3 测出管道上限，wrk 压出业务拐点，两者对照定位瓶颈，最后用真实日志校准安全余量。这套流程一个下午就能跑完，却能避免后续每一次”拍脑袋升级”。如果你需要，可以在下次活动前按这个清单演练一遍，把承载量的主动权握在自己手里。