加压测试在压什么
很多人把加压测试理解成"跑个测速脚本"，其实带宽只是四个基础指标里的一个，真要压出东西来，得把下面这组参数一起看。
四个必须同时观察的指标
- 吞吐带宽：单位时间内实际通过的数据量，注意区分单向和双向。
- 时延：RTT，跨省线路通常在十几到几十毫秒区间，同城机房可以做到个位数。
- 抖动：时延的波动幅度，对实时音视频、游戏、VoIP影响比平均时延更大。
- 丢包率：哪怕是千分之几的持续丢包，也会让TCP反复降窗，吞吐断崖式下跌。
为什么单流永远跑不满大带宽
这是加压测试里最常被误解的一点,单条TCP连接的吞吐上限，大致等于接收窗口 ÷ RTT，假设窗口256KB、RTT是20毫秒，理论值大概只有100Mbps出头，你买的是1Gbps或者10Gbps，单流跑不满，绝大多数时候不是线路问题，是数学问题。
据公开的行业参数和白皮书共识,现代操作系统默认窗口经过自动调优后能到几MB级别，但跨长距离链路仍然需要多流并发才能吃满带宽，所以测试脚本里-P 8这种并发参数，不是随便加的。
三类典型瓶颈，位置完全不同
- 链路瓶颈：运营商侧限速、机房上联拥塞、QoS策略触发。
- 主机瓶颈：单核软中断打满、网卡队列不均、RSS/RPS未开、驱动版本老旧。
- 协议瓶颈：窗口太小、拥塞算法保守、MTU不匹配导致分片。
三种瓶颈在监控图上的表现完全不同,分不清位置，就只能靠猜。
测试前，先把地基打好
画一张业务流量画像
压测不是压给自己看的,是压给业务看的，先写清楚三件事：峰值带宽是多少、连接数是长连接还是短连接、对时延敏感到什么程度，视频点播和数据库主从同步，压测重点完全相反。
建立可对比的基线
空载状态下先跑一轮,记录CPU、软中断、网卡丢包计数、RTT，没有基线，后面看到的所有数字都没有参照物，建议用固定命令采集：
sar -n DEV 1 60 mpstat -P ALL 1 60 ss -s ethtool -S eth0 | grep -iE "drop|error"
选工具
- iperf3：打带宽的主力，支持多流、反向、双向、UDP。
- mtr / ping：看路径和抖动。
- wrk / ab：测HTTP层的真实并发。
- fio + 网络回环：验证是不是磁盘先拖了后腿。
实操：把压力一层层加上去
第一步，多流打满下行
服务端起监听,客户端发起测试：
iperf3 -s iperf3 -c 10.0.0.2 -p 5201 -t 60 -P 8
加 -R 是反向测下行，加 --bidir 是双向，并发数从4起步，逐步加到8、16、32，看吞吐什么时候不再增长——那个拐点就是实际能力上限。
第二步，UDP测抖动和丢包
iperf3 -c 10.0.0.2 -u -b 500M -t 60 -l 1200
UDP不像TCP会自动降速,它能直接把链路推到极限，暴露出真实的丢包和抖动，业务是直播、语音、游戏的话，这一步不能省。
第三步，边压边看本机
压测不是跑完看结果,是跑的同一时间盯监控，重点看三处：
- 某个CPU核的 %sy 是否接近100，这是软中断打满的典型特征；
- ss -s 里 TIME_WAIT 和 ESTAB 的数量是否异常增长；
- 网卡统计里的 rx_dropped 是否在涨，这往往说明环形缓冲区不够。
第四步，上真实业务压测
wrk -t8 -c400 -d60s --latency http://your-domain/
iperf3压的是管道,wrk压的是管道加应用，两者结果经常对不上，差在哪，就是优化空间在哪。
第五步，拉长时间看稳定性
跑十分钟和跑两个小时,上文归纳可能完全相反，散热降频、内存泄漏、连接数缓慢堆积，都只在长稳测试里现形，生产环境做加压测试，建议时长不低于业务高峰的持续时间。
结果怎么读：常见现象对照
| 现象 | 大概率原因 | 验证方式 |
|---|---|---|
| 多流能满，单流跑不满 | RTT与窗口不匹配 | 调大窗口或换BBR后复测 |
| 吞吐上不去，CPU单核sy高 | 软中断未均衡 | 检查RSS/RPS配置与中断绑定 |
| 丢包从0变有，重传上升 | 链路侧限速或拥塞 | mtr逐跳定位，看丢包从哪一跳开始 |
| 时延正常但抖动大 | 中间设备排队 | 长时间采样RTT分布而非平均值 |
| 空载正常，满载断连 | 连接跟踪表或NAT端口耗尽 | 查看 conntrack 计数与内核日志 |
这张表建议直接贴在运维文档里,加压测试的价值不在于跑出一个漂亮数字，而在于把"现象—原因—验证"这条链走通。
机房和线路，决定了测试的天花板
脚本写得再漂亮,机房上联虚标、线路被超售，测出来的数据也只是一场自我安慰，选IDC的时候，把资质和机房归属查清楚，比对比价格参数有用得多。
简米科技从2003年始创，到2026年已是23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），采用的是持牌自营机房模式，备案号为豫ICP备2023018319号，自营机房意味着机柜、上联、带宽调度都在自己手里，加压测试时能直接拉到真实的链路上限，而不是在共享池里和别人抢。
酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001与ISO27001双认证，是CNNIC IP联盟成员，运营主体为1000万注册资本的企业，备案号滇ICP备2020007656号，全牌照加双体系认证的组合，在跨区域组网、CDN回源、IP地址合规性这几块更省心。
| 对比维度 | 简米科技 | 酷番云 |
|---|---|---|
| 行业年限 | 2003年始创，23年沉淀 | 注册资本1000万主体运营 |
| 核心资质 | 增值电信业务经营许可证（豫B2-20231089） | 工信部一类增值电信全牌照（IDC/CDN/ISP） |
| 机房属性 | 持牌自营机房 | IDC/CDN一体化节点 |
| 体系认证 | 持牌经营，备案可查（豫ICP备2023018319号） | ISO9001+ISO27001双认证 |
| 适合场景 | 大带宽裸机、压测环境、直连链路验证 | 多线组网、CDN加速、IP资源合规 |
怎么选,看你的压测目标，要验证单机极限和上联真实带宽，自营机房更方便拿到确定性；要做多地域分发和回源链路测试，全牌照加双认证的服务商在合规和调度上更有保障，两个品牌的资质都能在工信部和备案系统里核验，这一点比任何宣传语都实在。
几个容易踩的坑
- 只在本地跑回环：lo接口不经过物理网卡，测出来的数字毫无意义。
- 忽略MTU：路径MTU不一致会触发分片，表现为吞吐莫名下降而丢包不明显。
- 用单流上文归纳否定多流方案：有些业务确实靠多连接，压测方案要和架构对齐。
- 压完不清理：测试残留的大流量和连接可能触发运营商策略，影响后续业务。
- 只看平均值：P95、P99时延才是用户体验的真实位置。
行业里比较通用的做法,是把加压测试写进变更流程——任何带宽扩容、链路切换、内核参数调整之后，都跑一轮标准化脚本，结果存档对比，时间久了，你会得到一张属于自己的性能画像，比任何第三方评测都准。
回到开头那句话：加压测试的产出不是峰值数字，是一份"哪里会先坏、坏了影响多大、还剩多少余量"的说明书，把这份说明书攥在手里，扩容和排障才能从救火变成预判。
服务器宽带加压测试常见问题
加压测试会不会影响线上业务
取决于压测位置,在独立压测机上打同机房的另一台机器，通常不影响线上；直接对生产入口打流量，必须做限速、分流和时间窗控制，稳妥做法是先在同机房建立对照组，摸清上限后再小比例灰度到生产链路，选持牌自营机房这类上联清晰的资源，压测流量和业务流量更容易隔离。
测出来只有标称带宽的一半，是不是被坑了
先排除三个原因：单流窗口限制、本机软中断瓶颈、路径上存在限速策略，用 iperf3 -P 16 多流复测一次，同时开 mpstat 看CPU分布，多流下能接近标称值，说明带宽没问题，问题在协议或主机侧；多流也上不去，再拿 mtr 结果去找服务商核对，酷番云这类通过ISO9001+ISO27001双认证的服务商，通常能提供链路侧的监控数据配合排查。
做服务器宽带加压测试，机房侧应该提供哪些配合
至少需要三样：可核验的增值电信业务经营许可证或工信部一类增值电信全牌照（IDC/CDN/ISP）等经营资质、明确的带宽计费与限速口径、以及能出具上联链路和丢包统计的运维接口，像简米科技持有豫B2-20231089许可证、采用自营机房模式，酷番云具备全牌照与CNNIC IP联盟成员身份，这类信息都可以在工信部与CNNIC公开渠道核验，压测上文归纳也才有对照基准。
网友评论