最近分析了下基于Squid的视频业务的日志,发现一些比较不错的内容:
1:很多视频网站或者静态类网站都用Squid作为前端的缓存.其实对于大容量对象来说,内存命中和磁盘命中对于用户的下载速率影响不大,但是需要基于一个前提:磁盘的吞吐能力处于可接受范围之内.一般I/O等待不要超过30.包括缓存命中和未命中下载速率也影响不大,因为内网的带宽是足够的(最终还是取决于磁盘性能).总体来说,视频类的静态服务取决于磁盘的读写性能.
2:影响视频类服务质量最大的因素是带宽.一旦出口带宽不够(主要是高峰时刻),则影响的不仅仅是部分用户,它会将整个CDN服务的Server堵塞住,导致单机并发连接数过高,这时候单机的网卡出口带宽又会成为瓶颈,导致用户的下载速率急剧下降,造成雪崩效应.所以一些专业类CDN厂商其最大的资本就是拥有跟多的带宽.
3:每个产品应用都有高峰时刻应用,其实在不同的时间段内用户的下载速率也是趋向恒定的.假如出现很大的波动,说明服务架构存在问题.
目前无法说明不同时间段内,用户本身的下行带宽是否会影响服务质量.
4:结合服务器端和客户端的情况来看,大概有25%左右的用户下载速率小于100KByte/s.假定视频的码率为600,则需要用户的下载速率达到80KByte/s.相对于1M带宽的需求.而让我惊奇的是20%的用户下载速率大于1MByte/s.其实像我这样在公司上网的用户下载速分率能达到650-900KByte/s.
5:其实在25%的视频浏览用户具有拖动视频的习惯,而Squid最大的优势就是支持拖动功能,包括后端能够异步下载完整的视频并缓存住.
这也是很多高性能服务器(比如Nginx)目前无法做不到的,Nginx都是处理高并发,短链接的服务.而视频业务却是长链接的服务.
从我目前的感知来看Squid确实有优势.但是对于Squid了解不够,后续需要进一步学习.
6:一般一个视频片段播放6分钟,码率为600,则大概视频文件20M.可其实从日志上开,访问5M(不是实际大小)以内的视频大概占40%.说明用户的习惯是经常跳跃性看,并且这些用户的下载速率大于1MByte/s的用户占了35%.非常奇怪的一种行为.所以对于短视频的访问策略可以进一步优化.
上面统计了视频Squid的相关日志,从中也可以发现一些改造点
1:可以看出有15%的用户下载速率达到了1MByte/s.也就是用户在下载视频过程中,大部分视频文件10秒就能下载完成.那么这个说明了什么
(1) 极大浪费带宽,尤其对于大片,可能部分用户看了开头就直接关闭浏览器了.而实际视频文件已经下载下来了.等于极大浪费带宽.当然也有好处,比如用户拖动的时候其实直接在buffer中进行操作了,对用户的感受还是比较好的.
(2) 大部分用户的下载速率小于300KByte/s.而由于这些变态高速率用户会极大强制带宽资源,尤其对于单机来说,本身网卡的出口速率都是有限的.假如影响了正常用户,则平均下载速率就会下降,从而导致并发链接也过高.
针对这二种问题,我们会想到限速,那么可能会遇到那些问题呢:
(1)目前Squid具有限速的模块,但是做到何种颗粒度的限制无须多考虑,只能根据大概可接受的值,无法做到对于单个用户的限速.
(2)限速后,用户平均的下载速率会下降.导致单机的并发连接数过高.从而影响单机的处理性能.
总之限速这个功能已经成为专业CDN厂商必备的一个功能.包括实际的使用效果如何需要进一步思考.
2:日志中分析了用户实际下载的视频文件大小,但从服务器端来说,实际还是处理完整的视频文件,所以可以进一步分析热点视频切割后的文件大小区间分布.分析的原因主要考虑视频文件的存储规则.对于大视频业务来说,内存的大小决定了能缓存的文件个数.所以假如将小视频文件放入专有的大内存单机上,则命中率和效果将更好,前提还是单机的网卡出口不成为瓶颈.
3:现在的视频越来越追求品质,所以码率会进一步提升.那说明了什么问题:
(1) 一个500码率的视频文件,用户需要多少的下载速率进行下载.尤其对于初始下载的时候.
(2)针对不同的下载速率用户,可否采取一定的方法进行预加载,比如初始化的时候广告渲染的时候并行进行下载.
播放到多少的时候下载下一段的视频.
(3)播放器如何知道用户到某个CDN的下行速率(注意不是服务器端的下载速率).假如能知道,则可以选择加载高码率还是低码率的视频文件.这点实际比较难操作.