全球CDN节点测试的核心目的实际上只有一个, 那就是确认你的内容在全球各个区域的用户端那边的实际加载表现是不是真的达标。
这个测试主要是围绕5个核心指标来展开的, 这5个指标分别是平均响应延迟、丢包率、可用带宽、首字节时间以及完整页面加载时间, 这里面首字节时间的英文缩写是TTFB, 平均响应延迟的英文缩写是RTT。因为那5项数据会直接决定用户体验的好坏, 所以这已经是判断CDN节点质量最硬的依据了。
核心测试指标及合格阈值
平均RTT: 同一区域内部的节点之间的距离应该少于30毫秒, 而跨越不同大洲的节点之间的距离应该少于200毫秒。如果数值超过了这个标准的界限, 就说明当前的路由路径存在异常情况, 或者是某个节点本身的处理能力不够充足。
在正常的网络条件里, 丢包率得小于百分之一。要是某个节点的丢包率一直超过百分之五, 那这个节点基本就没法用了, 得把它删掉或者换一个新的。
可用带宽: 如果单个人去实测下载速度, 这个速度不能低于节点上标注的那个大带宽的百分之七十。要是发现速度比这个比例要低, 那就说明在这个节点那里存在了并发处理的瓶颈问题, 处理不过来那么多人的请求了。
当静态资源在CDN层面发生命中时, TTFB这个时间指标应当控制在小于50毫秒的范围之内。而在需要进行动态回源的特定场景下面对这种情况时, 该指标也应当严格低于200毫秒的阈值。
完整加载时间是以4G还是5G来作为模拟的网络的基准, 在这个情况下来说的话, 首屏的加载时间应该是要小于一秒五的, 而完整的页面的加载时间是必须小于三秒的。
常用测试工具与方法
标准测试执行流程
1. 我们需要去选取那些测试源。这些测试源要能够覆盖北美地区。还需要覆盖欧洲地区。同时还要覆盖东南亚地区。此外还要包含中东地区。以及南美地区也是必须覆盖的。关于这些测试源, 可以使用公共的VPS。也可以使用云厂商提供的轻量实例。
2. 为每个源龙南市就业服务平台，都分别地去向目标CDN域名发起TCP连接, 并记录DNS解析耗时与TLS握手耗时、还有TCP连接耗时, 以及请求-响应耗费的时间这四个部分。
3. 执行带宽下载测试, 让测试任务并行运行, 所选的文件大小要大于或等于100MB, 在此过程中, 把吞吐量曲线给记录下来。
4. 需要在目标页面上部署前端性能采集脚本, 让这个脚本连续运行超过或者等于24个小时来收集真实的RUM数据。
5. 需要对所有的数据实施汇总动作, 然后依据不同的维度情况展开具体的统计操作, 这些维度包含有地域区域划分、时间时期区分以及网络类别选择其中有线或者4G或者5G这些类型。
结果解读与优化方向
要是说, 某一个网络区域的往返延迟数据偏大。但是这个区域的带宽状况却一切正常。那就要把工作的重点放在检查, 这个区域的Anycast路由路径上面了, 或者看看BGP宣告的操作过程是否存在问题最终导致了次优路径的选择。
如果丢包情况集中在某个特定的时段里面, 那么大概率是因为上游的链路出现了拥塞的问题, 这个时候需要去和那个CDN供应商做一个确认, 看他们在该区域的节点容量水位到底是怎样的。
如果TTFB这个指标出现异常状况, 但是RTT这个指标还在正常范围内, 那么需要对CDN缓存命中率进行相应的检查操作, 一旦确认命中率的数值低于百分之八十这个具体界限的时候, 建议去调整源站端的缓存策略或者在原有基础上增加一层边缘缓存。
在具体的实际操作环节当中, 比较建议大家把测试脚本弄成定时任务的形式, 让每隔三十分钟就去执行一轮这样的操作, 并且要把得到的结果推送到监控大盘上面去。
大家可以在 gz88.cn 这个网站上发现一组开源性质的全球CDN节点拨测脚本模板, 这套东西是支持一键部署到各个不同区域的VPS之中的, 同时还能实现自动汇总报告的功能, 所以特别适合用于快速搭建起持续拨测这样的体系。
注意事项
测试结果必须要对“CDN边缘节点”和回源节点进行区分, 这两个部分对应的性能指标是不能混在一起使用的。
因为单一的时点进行测试, 得出的结果会产生比较大的波动, 所以必须至少提取连续7天的测试数据, 并且要将每天在上午8点钟、中午12点钟、傍晚18点钟以及晚上22点钟这四个不同时段所测得的中位数值汇总起来, 最后依据这些中位数数值来做出判定。
需要进行补充测试, 这种测试是使用模拟移动端网络的方法来完成的, 具体的情况包括3G、4G限速这样的条件存在, 这样做的原因在于避免得出一个错误的判断, 这个错误的判断内容是“一切正常”, 产生这种误判的原因是仅仅以桌面宽带环境为基础去进行检查所导致的。
完成上面的那些步骤之后, 你就能够拿到一份质量基线报告, 这份关于全球CDN节点质量的报告是可交付的, 也是可追溯的, 并且还能用来做对比。在以后的每一次变更中, 无论是进行供应商的切换, 还是调整区域的配置, 你都可以根据这份报告来做回归验证。
