莫让CDN服务成为小网站的瓶颈

2012-03-27

昨天晚上我在学校的机房上网(教育网),不自觉地打开了我的博客。因为刚刚给博客部署了新买的CDN服务(只为附件服务器部署),而且购买的CDN服务有教育网节点,所以我心想,我的博客的访问速度一定可以如飞喽。但事与愿违,博客的打开速度不仅没有提升,反而变慢了许多。而且通过浏览器的状态栏不难发现,载入时间最长的就是img.mawenjian.net域名下的资源,也就是部署了CDN服务的部分。

那么,这是什么原因造成的呢?

我首先从本地网络开始查起。我用的PC使用的线路是教育网的百兆共享,使用迅雷开下载,即使在忙时速度依然可以达到2~3MB/s。所以,瓶颈肯定不在本地网络这儿。

难道是因为CDN把我分到了一个非教育网的节点?我通过查询img.mawenjian.net域名所指向的IP归属及使用ping命令后发现,CDN并没有分错节点,而且本地PC到该节点的延时只有4ms。所以问题也不在这里。

不是节点的问题,那应该是源站的问题喽。但是我的www网站和img.mawenjian.net的源站使用的是同一个IP,我本地PC打开www网站速度流畅,这就说明了不是因为源站点拥塞而造成的。

既然前三个猜想都不是出现瓶颈的因素,那么原因只有一个——CDN节点!尽管这个结论有点让人难以相信,但是事实摆在眼前,不得不接受啊。可能你听到这里有些糊涂了,怎么就是CDN节点产生的瓶颈呢?且听我一一道来。

首先需要从CDN技术的原理说起。CDN的原理嘛,说白了就是缓存,即将内容缓存在离用户较近的节点上。当用户需要获取内容时,只要从距离“最近”的节点获取即可。因为这个“最近”的节点往往和用户位于同一网络,物理位置距离较近,带宽又比较充足,所以速度较快,给人以一种被加速的感觉,所以有时候也将CDN技术叫做“CDN加速”。

从我上面的表述中不难发现,CDN加速能否成功,很大程度上依赖于CDN节点上是否有要获取内容的缓存。而缓存内容是怎么获得呢?是当有用户访问该内容后产生的。如果该内容没有被缓存,CDN节点则需要作为客户端向源站点请求数据。

因为我的博客访问量实在太小了,以至于造成缓存的命中率很低(教育网节点更是接近于0),进而CDN节点频繁回源取数据。在我打开我的博客的过程中,CDN节点其实是在进行2个操作,即从源站点取数据和将取到的数据传送到我本地PC。这样一去一来,实际上CDN节点的流量是乘以2的。由此可见,CDN节点对带宽的要求是很高的。但是因为我的上网时段处于上网高峰期,CDN节点带宽紧张(可能跑满了);而且我的源站点位于非教育网,但是教育网节点回源时却使用教育网线路,此时就会面临因互联互通问题造成的传输时间变长,进而形成了上述问题——使用CDN的资源比没使用CDN的资源还慢。

通过这个事情我们得出了一个结论,即在使用CDN技术时,不要盲目相信多节点,也不要盲目相信多线路,CDN节点的选择很重要。一旦CDN节点选择不慎,很容易出现问题。比如我原先使用的盛大云DDS,虽然节点数不多,而且没有教育网节点和线路,但是带宽充足,教育网方面的表现却比上述CDN服务要好的多。又比如我曾经使用的某免费CDN,因为带宽有限,所以经常出现文件加载不完全的现象,非常影响用户体验。

另外,对于小站点而言,尽量使用BGP线路或者多线线路来代替CDN服务,CDN技术的原理决定了CDN对小站的加速作用十分有限。当然,如果支持主动内容推送的话,这种状况可能会有所改观。

最后,使用CDN服务时,恰当的缓存策略很重要。比如不需要经常更新的图片、CSS文件、JS脚本文件等,可以通过设置一个较长的缓存时间来提高缓存命中率。像我购买的上述CDN服务,虽然系出名门,但是因为是从代理处获得的,不能自定义缓存规则,所以无法设定最优的缓存策略。因此,这对于上述问题的产生也是一个不能忽略的重要因素。


除非特殊说明,本博客文章均为原创,转载请以链接形式标明博文地址。

本文链接地址: 莫让CDN服务成为小网站的瓶颈

分类:互联网 | 标签: |

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注