过去很长一段时间一直认为在服务器端对用户进行访问限速会使用户的浏览体验变差，是一种负优化，直到最近才发现对用户进行合理的限速也能改善用户的访问体验。
事情还要从一个多月前说起，在例行进行服务器检查的时候，发现几台Nginx缓存服务器的带宽波动非常大，经常短时间内顶满带宽，然后又降回到非常低的水平，害的我强迫症都犯了，到底要不要增加带宽呢？不增加的话，带宽顶满对用户体验来说肯定是会有影响的，但如果增加了带宽，一半以上的时间带宽使用率又非常的低，显然老板不会同意。
还是先从日志入手吧，随手翻了翻几台缓存服务器的日志，基本可以确定带宽顶满的时候是在进行视频文件的请求，经过上一次的教训，现在所有的视频文件都是从缓存服务器上直接读取缓存文件的，每个视频文件大小基本都在30-50M之间的样子，倒也不算太大，但访问量上去了以后的带宽占用情况还是比较可观的，就算每台服务器平均有5个视频连接并发，按目前顶满带宽的情况下，每个请求差不多只要5-10秒的样子才能完全下载完成。
但项目上用到的视频又不多，大部分的时间其实是没有视频文件的请求的，但一旦有视频文件的请求，哪怕是只有一个请求，由于视频文件偏大，还是会在短时间内把带宽顶到满的，这就造成了部分用户访问项目出现忽快忽慢的情况。
问题原因找到了，解决起来也就简单了，因为大部分视频文件的时长都在1分钟以上，并不是所有的用户都会耐心的把完整的视频都看完，所以完全没有必要让用户在几秒的时间将完整的视频下载到本地，只要能让视频保证流畅播放就可以了。
把几个稍微大点的视频拉回到本地研究了一下，发现视频的码率也就只有1-2M的样子，换算成带宽最多也就200K的样子，保险起见给到他两倍以上的缓存带宽应该是不影响播放体验的，所以这里就配置Nginx缓存服务器使用自带的功能对视频文件的下载进行限速处理，使用到了下面的配置参数。
limit_rate_after 5m; limit_rate 512k;
这两个参数的意思是，当文件加载完5M以后，将该文件的下载速度限制到512K，这样即可以快速的把视频的前几秒下载回来，又可以对后续的视频缓存进行限速，这样就可以流畅的播放项目里用到的所有的视频文件了。而且因为有条件限制，所以并不会影响到5M以下的图片文件和其他网站文件的加载速度，真是一举两得。棒棒达！
重新配置以后上线观察了一段时间发现效果明显，不但页面加载速度更快了，而且带宽占用率也有明显降低，老板再也不用担心带宽会被顶满了，带宽稳定在了一半不到的位置，估计大部分人都不会把那烦人的视频完整的看完吧。再观察一段时间看看，如果带宽稳定下来，甚至可以考虑把现有的带宽稍微降一点。
0 条评论。