多线程下载引起的squid缓存命中率低

最近帮一合作的IPTV厂商在联通机房搭一个squid缓存，用于缓存IPTV的试听音源。运行一段时间后发现缓存命中率极底，连5%都不到，查看访问日志后看到同一个音源有多个请求且http返回码都为206，这应该是合作厂商在试听过程中使用了多线程。多线程将一个文件被分成多个块同时下载，加快下载的速度，但同时由于每个请求都只是内容的一部分，所以squid不会缓存，下次请求时依旧会打到后端。

原因找到后问题就好解决了，在squid的配置文加上如下配置：

range_offset_limit -1

quick_abort_min -1

range_offset_limit  主要是对各种流媒体和要断点续传的文件的缓存的。缺省是0，也就是说只要client发过来的http header里包含了“Range:” ，squid会把这个请求转到后端http server且http server返回的内容并不会进入squid的cache store。把它的值设置为-1；然后squid会把Range头去掉，预先从后端http server把内容全部抓下来，放到cache store里，随后的对该cache的访问就不再转发到后端http server，可以大大提高命中率。

需要注意的是，range_offset_limit  设为-1后squid服务器的流量有可能大大超过用户正常访问需求的流量，这是因为当用户开启了多线程如并发10个线程从这个节点下载，预先读取的参数会同时用10个并发来缓存，相当于一份文件下载了10次，在第一次请求时一个100M的文件有可能下载到squid节点中100M*10(并发)=1000M，直到其中最快的一个并发都预先读取完了所有的要下载的那个文件才会将文件缓存起来，之后请求才会从缓存中得到文件。

(quick_abort_min  quick_abort_max quick_abort_pct) 配置当用户中途断开请求时squid如何处理。当用户中断请求时，squid将检测 quick_abort 的，如果剩余部分小于“quick_abort_min”指定的值，squid 把继续完成剩余部分的传输；如果剩余部分大于“quick_abort_max”指定的值，squid 终止剩余部分的传输；如果已完成“quick_abort_pct”指定的百分比，squid把继续完成剩余部分的传输。设成-1后当用户中断请求时不管剩余部分还剩多少都会完成剩余部分的传输。

 

改了配置运行一段时间后，squid的命中率大幅上升，如下图：