你在选服务器的时候看过一份测评，上面写着这台机器实测能跑到某个带宽数字，比隔壁那台高一截。你按这个数字下了单，上线之后发现，白天访问高峰时页面加载明显比测评里描述的要慢。这不算被骗，那个数字本来就是能力上限，从来不代表你能稳定拿到的东西。更值得留意的是，这种落差往往不是一次性的。它在高峰期反复出现，你会慢慢把它当成白天就是这样，然后错过真正该做的那次调整。
平台官方文档其实写明了。在介绍实例规格指标时有一句几乎固定的说明：这些指标均在纯转发测试环境下验证获得；实际业务场景中，受实例负载类型、包长大小、长短连接、镜像版本、组网模型等因素影响，性能表现可能存在差异，建议先进行业务压测再决定规格。这句话出现在每一项指标后面，但真正读完的人不多。
纯转发测试是什么意思？简单说就是在最理想的条件下只做数据转发，不跑真实业务。它的作用是把一台机器的能力上限标出来，而不是给你一个承诺值。这有点像油耗标称：那个数字是特定条件下跑出来的，你日常开肯定不一样。两件事都真实存在，但只有前者会被印在最显眼的位置。理解了这一层，你就不会再去纠结为什么测评说能跑那么快我却跑不到。两句话说的不是一件事：一句在描述机器能力的边界，一句在描述你的业务实际能拿走多少。
还有一个更关键的词叫突发带宽。有些平台会把带宽分成基础带宽和突发带宽：基础带宽是你正常情况下能拿到的；突发带宽是在基础之上短时间内能冲到的峰值，靠突发积分实现。官方对这个机制的表述相当坦白——它是利用闲置资源的让利，不承诺SLA。换句话说，别人在用的时候，它就未必轮得到你。
这条该怎么用，官方其实给了答案：如果业务有明确的带宽需求，选型时请参考基础带宽，不要参考突发带宽。这句话基本把使用方式说完了。你按突发带宽算容量，等于按最好情况做规划，而流量高峰恰好是最不可能有闲置资源的时候——你要冲峰值的那一刻，正是别人也在冲的时候。顺着这个逻辑还能推出一个更实际的结论：如果你业务的常态流量已经接近基础带宽，那说明你早就该升级了，而不是指望突发带宽帮你顶住。突发带宽是余量，不是产能。
那为什么测评数字普遍好看？因为测评本身也是在受控条件下做的。测试机可能只有一个访问者，跑的是单个大文件，没有并发、没有慢查询、也少算了TLS握手的开销。真实站点里一个页面要拉几十个请求，图片、脚本、样式各自都要建连接。这两件事之间的距离，往往比两个厂商之间的距离还大。
所以测评还有没有用？有用，但要换个读法。把它当成这台机器能到什么程度的上限参考，而不是我上线后能拿到多少的预期值。更有价值的反而是报告里的细节：测试用的包大小是多少、并发多少、持续了多久、有没有说明是在纯转发环境里跑的。把这些写清楚的测评，比只给一个峰值数字的可信得多，也更容易判断跟自己的场景像不像。看测评的时候还要注意它的测试时间。如果全都是在凌晨做的，那它测的其实是这台机器最空闲的时候，跟你的访问高峰正好错开。规范一点的报告会把测试时段也写清楚。
自己怎么测才算数？最省事的办法是拿真实业务去压。不是跑一遍测速脚本，而是按接近真实的比例去打：多少静态请求、多少动态请求、多少并发、持续多长时间。重点观察两件事：一是响应时间在什么量级上开始变差，二是连续压一小时之后，带宽和延迟有没有往下走。后面这一条能看出这台机器的资源到底是不是真的独享。压测还有个小技巧：别只压一次。同样的脚本隔几个小时再跑一遍，对比两次的数字。如果差得多，说明这台机器的性能受邻居影响明显，独享程度不高。
还有一类差别只在长期运行里暴露。有些机器跑单次测试很漂亮，连续跑几天之后开始出现抖动，因为差异来自宿主机上的邻居、来自磁盘IO的争用、来自网络出口的拥塞。这些东西不会出现在任何一份测评里，因为没有哪份测评会跑上七天。可你的站点是要长期在线的东西，评估维度里本来就该包含时间这一项。
带宽这事，看清两个词就够：一个是基础带宽，一个是不承诺SLA。前者决定你能规划什么，后者提醒你别把峰值当常态。选服务器不必迷信测评里那个数字，把自己的业务压上去跑一轮，比读十份报告都直接。别人测出来的好看数字，和你付钱之后拿到的东西，中间隔着的正是那句仅代表测试环境。最后补一句：带宽数字是可以被做出来的，但你的用户不会看那个数字，他们只看页面多久出来。把评估的锚点从测评报告挪到用户的真实等待上，选型的判断会简单很多。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
