定量的CDN加速效果分析

指路牌

• CDN
• 网站静态资源加速
• 定量展现CDN加速效果
• CDN配置好了可是没有加速效果？

适用场景

• “第一次接触”用户体验提高
• 网站具备大量图片、css、js等静态资源
• ECS购买了固定带宽，带宽成为性能瓶颈

环境

• 一个已完成“备案”的域名

域名购买后须要实名认证+备案，大概须要花费“14～20天”。

• 开通阿里云CDN服务

参考博客

Web项目汇集地 --- 一文读懂 CDN 阿里云 --- CDN文档

背景

我曾接触过两个项目，一个是基于web的AR项目，一个是使用了大图的展现性项目。两个项目都有一个共同特色：加载速度很慢。慢到什么地步呢？页面彻底加载完的时间量级均在两位数（10s左右），极端状况下甚至会达到20s甚至更久。

如此打开速度对于一款应用的体验来来讲是灾难级的，由于不会有一个用户有耐心等待如此长的时间，web前端针对加载速度慢在技术上具备不少解决方案：如使用一张像素很低体积很小的图片先显示以“安慰”用户，或使用分批加载等。

但以上两种方案都没法解决我碰到场景的问题，由于AR项目的js文件与AR文件都一样庞大，以上方案都不能彻底挽救两位数量级加载时间的灾难级体验。

幸运的是两个项目都是展位性质的，只须要利用浏览器自身的缓存机制，提早打开几回页面就能将加载时间将时间轻易降到50ms附近，让观众户彻底感受不到加载的耗时。

可是如此雨来，展现的互动性将变得很受限，由于用户没法使用本身的设备亲自打开体验应用，只能使用讲解员手中提早缓存好数据的设备。

我调研CDN的初衷，也是为了尝试解决以上问题：可以让彻底没有缓存用户的设备在“第一次接触”应用时可以较快打开应用，提升互动性。

原理&思路

要解决现有的问题，那么须要先分析一下性能瓶颈到底出在了什么地方。网页加载速度慢的根本缘由固然是文件过大，但监控服务器资源占用等参数后我将参数锁定在了两个：地理位置、带宽。

接下来咱们就来看看CDN到底能不能实现加速，以及可以加速到什么地步？

步骤

为了肯定上面两个问题，我选取了项目中的部分文件做为用例，作了一系列测试，获得三组对比数据以下：

1、境内外ECS对比

• “行”为该文件加载耗时，单位为ms、s
• 时间读取自Chrome控制台
• 禁用了浏览器cache，为了不偏差每次测试前均再一次手动删除缓存图片与记录。
• 每一个文件在一个ECS测试3次，所以每一个文件一共2组，6个数据。
• AWS的ECS在带宽上远比Ali的ECS高，Ali这的ECS的带宽为固定带宽5Mbps（也即0.625MB/s）。

现象

• 位于奥兰多的服务器和位于张家口的表象不相上下，
• 文件大小达到4MB左右均会开始向10s逼近，

结论： 因为空间位置缘由没法获取文件在奥兰多处的加载耗时，不严谨的得出结论：AWS在带宽上弥补了物理距离的差距，两者速度差别不大。

2、在AliCloud的ECS，使用CDN加速与不使用CDN加速对比

C、D、E三列为先前测试数据 F、G、H、I列为使用CDN加速后测试数据 G为同局域网下同事电脑 H、I为使用手机热点4G网络下在另外一台设备Mac上的时间表现

现象

• F列为本人PC，具备很是明显的加速效果，
• G、H、I三列均没有任何变快表现，甚至还更慢了......

结论：

• Ali的CDN难道是针对单个IP进行加速，来欺骗消费者的吗？

这个结论固然是错的，可是数据上又呈现出了以上特色，又是什么缘由致使的呢？继续往下看

3、在AliCloud的ECS，使用CDN加速，并进行“数据预热”后数据对比

C、D、E为第一组测试数据，无CDN状况下性能表现 F为第二组测试数据，进行CDN加速但无数据预热时在一台新设备上的性能表现 H、I、J为使用CDN加速后，分别在同事G与另外两个彻底没有开过网站的设备上打开网站的性能表现。

现象

• 在没有数据预热前，CDN加速基本没有任何提速效果
• 进行数据加热后，文件加载数据明显提高很是多。

结论

• CDN在数据预热后实现了网站加速的效果，对比数据预热先后同事G设备上的性能表现，加速效果大约在5～15倍之间。

从最后的效果效果来看，将文件打开速度由10s级降到将近ms级，确实极大优化了用户“第一次接触”的用户体验，可以让用户有耐心讲应用使用下去，也可以在展位上让观众可以使用本身的设备打开服务，对交互和受众面的提高都具备很是大的好处。

后记

觉得这就完了？后面还有内容，量化说明CDN的加速效果并非这篇文章的主要目的。

“数据预热”这一名词时在CDN的原理文章比较少提到的，在获得第二组测试数据的时候，我就十分困惑的提交了工单，才得知了“数据预热”这一环节。进一步和工程师询问得知，AliCloud的CND默认是抢占式的，就像硬盘与内存的映射关系，使用越频繁，加速内容在冗余站点的存放时间与获取资源也会越多。

所以个人PC所接入的加速站点具备很好的加速效果

而低频或刚添加的资源默认并不会传输到冗余站点，须要在控制台手动进行“数据预热”。且即便预热后，长时间不使用也会从冗余站点抹除，被替换掉。固然，从所支付的费用来讲，这一抢占机制是很合理的，毕竟我完成全部测试也只花费了0.26RMB的费用。

在第三组数据中，应该能发现即便数据预热后，加速效果在不一样设备间的表现效果也是存在差别的，如在同事C设备上，加载数据都在ms级，而在同事G与与同事L设备上，倒是个位数的s级。细心的读者也许会发现，我在CDN设备上面都标注了一个地理信息，个人我的PC是湖北、同事G是山西，同事L与同事C是甘肃。（在第二组数据中因为还不清楚这个概念，当时没有记录）

这些地理位置，是AliCloud冗余加速站点所处的地理位置的信息，这里一个颇有意思的现象是，以上全部4台设备都是处在同一个局域网下的4个独立的设备，3台Win，1台Mac，走同一个网关接入因特网，但每一台设备接入的CDN加速站点都不相同！

两个同属甘肃的服务器IP不相同 同一台设备接入的冗余站点始终相同

也由于以上缘由，致使他们加速效果存在差别，这一点是让我很是不理解的，为何同同一个局域网下的设备接入加速站点的位置却有如此大的差别？接入冗余加速站点的规则究竟是怎样的？这是我一直没有弄明白的问题，在工单上询问工程后也没有获得明确的回复，姑且只能搁置于此。

要获取更多Haytham原创文章，请关注公众号"许聚龙":