优先盯紧回源成功率、回源响应时间、回源带宽峰值和源站错误率这四个指标，它们直接决定CDN节点回源时源站扛不扛得住、业务会不会断。
很多团队做回源压力测试,上来就猛打流量，结果测完只拿到一张“所有节点都正常”的报告，源站该挂还是挂，回源压力和普通压测不一样，它测的不是用户边缘节点的体验，而是源站的真实承载极限，如果你正在规划CDN架构，或者准备做一次大促前的容量评估，这篇文章帮你把指标体系拆清楚，照着盯就行。
回源压力测试的核心指标分层
回源链路是“用户→CDN边缘节点→中间层→源站”的完整路径，压力测试时，每一层都有各自的瓶颈，行业共识认为，指标必须分层看，不能混为一谈。
第一层：源站视角的硬指标
源站是回源链路的最末端,也是最容易被打垮的环节，源站相关的指标是所有回源测试的“硬通货”。
- 回源成功率：这是最直接的生死线，回源成功率低于阈值，意味着用户请求在源站层面已经出现了实质失败，测试时要区分HTTP层成功率（比如2xx/3xx占比）和TCP层成功率（连接建立比例），多数情况下，TCP连接失败比HTTP错误更危险，因为说明源站已经无法维持基本连接。
- 源站响应时间（TTFB）：从源站收到回源请求到返回第一个字节的时间，这个指标直接反映源站应用逻辑、数据库查询、缓存命中等处理速度，回源压力下TTFB会明显上升，如果超过500ms（动态接口）基本就不可接受了。
- 源站CPU/内存/负载：虽然不算网络指标，但回源压力测试必须记录，CPU跑满但成功率没降，说明源站还在硬扛，继续加压就会断崖式下跌，内存持续增长可能指向内存泄漏，这在长时间回源压测中特别常见。
- 源站带宽出口：很多源站部署在云上，带宽是硬上限，回源测试时源站出口带宽打满，会出现大量丢包和重传，表现为成功率下降但源站CPU并不高，这个场景特别容易误判成“源站性能不够”，实际上是带宽限速。
第二层：CDN节点与回源链路指标
CDN节点是回源的发起方,节点与源站之间的链路质量决定了回源体验，只看源站不看链路，等于把问题藏在了中间。
- 回源带宽峰值：所有CDN节点同时回源时，在源站入口汇聚的总带宽，这个值决定了你的源站需要预留多少带宽资源，也决定了是否需要做限流或分层回源，回源带宽峰值通常出现在缓存命中率最低的瞬间，比如首次访问高峰或缓存过期后的集中回源。
- 回源请求数（QPS）：每秒回源请求量，QPS比带宽更敏感，尤其对动态请求或API接口，静态文件大带宽低QPS，动态接口小带宽高QPS，两种场景源站承受的压力完全不同。
- 回源链路质量：包括回源TCP建连时延、TLS握手时延、首包时延，链路质量差时，CDN节点会不断重试，导致回源请求数成倍放大，源站负载虚高，测试时要特别关注不同地域节点的回源时延差异，如果跨地域回源，时延会显著放大重试概率。
如何设计回源压力测试的指标采集方案
指标再多,采不准等于白测，很多团队用源站监控面板看数据，但回源压力测试是瞬时的，需要秒级粒度，建议从三个层面搭采集方案。
源站侧：埋点与日志并用
- 在源站前面接入负载均衡或网关,记录每个请求的回源IP、请求路径、状态码、响应时间。
- 源站应用层要打印完整访问日志，包含处理耗时、后端调用耗时、缓存命中状态，只靠负载均衡日志看不到应用内部耗时。
- 定期抓取TCP连接状态，统计SYN_RECV、TIME_WAIT数量，判断源站是否出现连接堆积。
CDN侧：利用控制台和API
- CDN服务商控制台一般提供回源监控模块，展示回源带宽、回源QPS、回源成功率，测试前先确认这些指标的统计粒度是否支持1分钟甚至1秒，很多控制台的默认粒度是5分钟，完全不够用。
- 部分云厂商开放回源日志导出接口，可以拉取节点维度原始日志，如果测试规模大，建议直接对接日志服务做实时聚合分析。
- 在CDN配置中主动区分不同回源策略，全部回源”和“仅回源失败时回源”，对比两种策略下指标差异，这也是回源压力测试的一个常见变体测不同回源策略对源站的影响。
链路侧：抓包与拨测结合
- 在源站服务器上使用tcpdump抓包,过滤回源IP网段，分析TCP重传率和乱序比例，重传率超过5%就说明链路质量已经大幅劣化。
- 使用云拨测工具,从多个CDN节点地域模拟回源请求，观察各地区的回源时延分布，注意拨测要覆盖电信、联通、移动三网，不同运营商的回源路由差异很大。
回源压力测试指标与业务场景的对应关系
指标不是孤立的,不同业务场景下，重点指标完全不同，测试前先明确业务类型，否则指标选偏了，测完发现和生产事故对不上。
静态资源加速场景
典型场景是图片、CSS、JS、视频文件分发，这类业务回源特点是大带宽、低QPS，缓存命中率通常较高，回源压力测试应重点抓回源带宽峰值和回源成功率，QPS相对次要，测试时要制造“缓存全部过期”的极端场景，比如清空节点缓存后直接上量，观察源站在满带宽回源下是否出现TCP丢包。
动态请求加速场景
典型场景是API网关、SSR页面、交易系统，这类业务缓存命中率低，甚至完全不缓存，回源QPS直接等于用户请求QPS，重点关注源站响应时间和回源QPS，测试时要模拟不同比例的热点请求和均匀请求，热点请求会导致源站某个服务或数据库连接池先被打满。
混合场景
很多真实业务是动态和静态混在一起,比如电商页面，HTML是动态的，图片和JS是静态的，这类场景建议按比例混合压测，观察回源带宽和QPS同时上升时，源站是CPU先到瓶颈还是带宽先到瓶颈，判断方式很简单：加压后如果TTFB上升但CPU不满，优先查带宽；如果CPU满而TTFB上升慢，查应用层线程池和数据库连接池。
回源压力测试指标的阈值参考
行业内没有统一的回源指标标准,因为每个业务容忍度不同，但根据公开的运维经验，有几个常用的参考区间，可以作为初始评估的基准。
| 指标 | 健康区间 | 需要警惕 | 说明 |
|---|---|---|---|
| 回源成功率 | ≥99.9% | 低于99.5% | 低于99%建议立即停止测试 |
| 源站TTFB（动态） | ≤200ms | >500ms | 超过1s用户体感明显卡顿 |
| TCP重传率 | ≤2% | >5% | 说明链路丢包严重 |
| 源站CPU使用率 | ≤70% | >85% | 超过85%后延迟会非线性增加 |
| 回源带宽利用率 | ≤70% | >90% | 超过90%存在突发丢包风险 |
这些数值不是硬性标准,但可以帮你快速建立“回源压力测试结果到底算好还是算坏”的判断框架，在实际项目中，建议先压到源站可接受极限的80%跑30分钟，再逐步加到100%、120%，每一步记录上述指标的变化趋势。
常见误区与排查思路
回源压力测试最容易踩的坑,不是指标没看，而是指标看错了对象，或者根本没把指标和现象对应起来。
- 只看CDN控制台，不看源站
，控制台显示回源成功率100%，但源站已经出现大量5xx错误，原因是CDN节点有回源失败重试机制，重试成功后在控制台显示的仍然是成功的回源请求，这种场景必须结合源站日志和CDN日志双向比对，才能暴露真实失败数。
- 忽略回源重试放大效应，当一个节点回源超时，CDN会重试，重试次数多的节点会让源站收到成倍的请求压力，测试时如果发现源站QPS远大于CDN统计的请求数，说明重试放大了压力，这时要主动降低回源超时时间，或者开启CDN的“失败时降级”策略。
- 测试时长太短，很多压测工具默认跑几分钟，但源站的内存泄漏、连接池耗尽、慢SQL累积等问题需要持续加压才暴露，至少跑30分钟，观察指标是平稳还是缓慢上升，缓慢上升比瞬间飙升更危险。
回源压力测试结果如何应用到容量规划
拿到指标后的下一步,是转化为源站扩容、CDN配置调优的决策依据。
- 如果回源带宽峰值接近源站出口带宽上限，优先升级源站带宽，或者开启CDN的“分片回源”功能减少单文件回源流量。
- 如果源站TTFB在请求量上升到某一点后急剧恶化，说明应用层线程池或数据库连接池达到上限，此时调大连接池参数比增加机器更有效。
- 如果回源成功率在某个区域节点上率先下降，检查该区域到源站的链路路由，考虑源站多地域部署或增加中转节点。
常见问题解答
回源压力测试和普通压测有什么核心区别？
普通压测关注用户侧的响应时间、可用性和吞吐量，测试对象是整个访问链路，回源压力测试专门针对“CDN节点回源到源站”这一段，核心指标是回源成功率、回源带宽、源站负载，普通压测不关心回源链路，回源测试则要把CDN缓存因素排除掉，直接观察源站的极限承载能力。
回源压力测试时CDN缓存要不要清空？
需要,如果不清空缓存，大量请求在节点就返回了，回源流量远低于实际风险值，正确的做法是把测试域名的缓存有效期设置为0，或者直接使用一个不缓存的新域名回源到同一源站，确保所有请求都穿透到源站。
回源带宽峰值和回源QPS哪个更值得关注？
取决于业务类型,静态资源占比高的业务盯带宽，动态请求占比高的业务盯QPS，如果两者都高，实际上是对源站的双重压力叠加，这时要特别关注源站CPU和内存的联动变化，通常带宽先到瓶颈时CPU还有余量，而QPS先到瓶颈时CPU和内存会同时告急。