From:http://www.codesky.net/article/200805/118486.html


公司的网站使用Squid 2.6STABLE2作缓存加速服务器,缓存的命中率一直不好,最好也只能达到90%,折腾了许久,终于发现影响最大的原来只是一个小参数,不过期间也学到了不少东西~


起初,考虑缓存命中率不高,考虑是不是给Squid的内存不够,所以就加大了内存配置,2G内存的机器给Squid 1G用,测试了两天,结果基本没有什么大的改变;于是调整refresh_pattern的参数,增大内容缓存时间,测试了两天,效果也不理想。


从kxn的文章中知道可以使用Expires模块让Apache给文件指定缓存时间,期望可以提高缓存性能,于是在服务器上:

ExpiresActive On

ExpiresDefault A2592000

结果第二天一早发现缓存命中率竟然比前一天还下降了2个百本点,有点晕了~


于是将cachemgr配置起来,详细地检查squid的运行状况,发现1G的内存缓存实际只用了不到300M,所以显然不是内存不够的问题。


为了充分利用内存,将maximum_object_size_in_memory调大到128KB,让其可以缓存更大的文件,而不是默认的8KB。顺手将ufs换成aufs,启用异步IO。


之后情况稍有改善,1个小时之后,内存的占用达到了1G,但命中率并没有明显上升。


于是又调整了内存的覆盖策略(memory_replacement_policy),听从kxn的教诲,使用lru,发现变化不大,也许是我们的访问量还不大的原因吧。


这时候缓存命中率仍然在90%以下徘徊。是不是我们的网站结构影响只能达到这么高呢?但是网站结构我没有办法改变,所以还是要从其他方面入手来解决问题。


于是使用Cache Manager 仔细的查看各个统计数据,当看到In-Memory and In-Transit Objects项目时,发现一个问题,那就是所有的网页文件都显示NOT_IN_MEMORY,这就比较奇怪了,问什么访问量最大的网页文件竟然没有被缓存到内存呢?是因为文件太大还是因为文件请求的数量太少,所以才没有被缓存呢?于是找了一个页面作测试,使用工具查看了返回的大小,只有40K多一些,与我的maximum_object_size_in_memory最大值128KB还有相当大的差距,所以不可能是这个原因。于是有使用ab程序对这个页面做了1000次请求,心想这下总会缓存了吧。可是查看缓存内容,依然没有,而且不但内存中没有,就连硬盘上也没有!


至此得出结论,一定是什么原因阻止了Squid对这些网页进行缓存。仔细的检查In-Memory and In-Transit Objects中的内容,发现IN_MEMORY 状态的对象基本都是jpg和gif图像文件,html,css等文本文件内容则都没有缓存。


这两种文件有什么不同吗?记忆中Squid也没有对这些文件类型的设定呀,refresh_pattern对所有的静态文件的设置也都是一致的,所以差异不应该来源于squid本身——也就是因为这种记忆使得我后来多费了许多的功夫~


在Apache上找到了文本文件与图像文件之间设置的差异——deflate压缩。是不是所有使用deflate压缩的内容都不会缓存呢?使用同样的squid软件版本及配置文件,相同的Apache软件版本和配置,快速的搭建了一套测试环境。squid只有1台,重建其磁盘缓冲区,重新启动squid,观察内存中对象的变化。果然,对于deflate压缩的内容,squid内存中没有缓存,磁盘也找不到。停止apache的deflate功能,重新请求页面,立即在squid的内存中查到了内容的缓存,这么看来是squid和deflate不太兼容了?


好吧,先将产品环境Apache的deflate停掉,过了一段时间,有两台squid的缓存命中了提高到了94%,虽然只提升了4个百分点,但是这充分验证了squid和deflate不兼容的观点。


然而,事情到此才刚刚开始!


难道Squid真的无法缓存deflate压缩的页面吗?好吧google一下,squid+deflate,在squid的邮件列表中找到了一些讨论deflate的东西,属于比较古老的吧,说因为deflate压缩之后,会产生Content-Encoding: gzip这样的HTTP头部,属于HTTP/1.1的内容,而Squid并不完全兼容HTTP/1.1之类的,需要用Transfer-Encoding之类的代替,可是mod_deflate和mod_gzip产生的头部就是Content-Encoding,怎么办?


为了解决这个问题,引入了另一个Apache的模块,mod_headers,用它来改写HTTP应答的头部,将Content-Encoding更改给Transfer-Encoding,可是,很自然的,页面一片乱码!说明此路不通啊!


又以Content-Encoding为关键字,快速的搜索了一下squid 2.6STABLE2的源代码,也没有发现几个地方用到这个东西,无果。


继续Google之,squid+can’t cache+Content-Encoding找到一篇文章,其中说’SQUID would never bother to cache ANYTHING that had

a “Vary:” header on it.’ 看来Squid缓存内容与Vary: 头部有关系。再次检查一下HTTP请求返回的头部内容,发现对于deflate压缩的内容,拥有”Vary: Accept-Encoding”这样一个头部,而没有经过deflate压缩的内容则没有这个头部,这次看来问题比较清楚了,因为deflate压缩添加了Vary: Accept-Encoding这个头部,导致了内容无法被squid缓存。


那么难道真的没有办法让squid缓存deflate压缩之后的内容吗?


基于上面的经验,很自然的想到使用mod_headers模块的功能将Vary头抹掉Squid不就可以缓存了吗?后来一想,这样会有其它问题:1)如果用户浏览器不支持gzip压缩功能,那么将无法正常的浏览网页;2)其它可能很重要的Vary内容也没有了,可能会导致更大的隐患。那么这种办法不行。


还有其它的办法吗?再次的快速搜索了Squid的源文件中关于Vary的内容,在Changelog中找到了这么一条:

- Full ETag/Vary support, caching responses which varies with request details (browser, language etc).

也就是说已经完全支持带ETag/Vary头部的内容缓存了。这一条出现在Changes to squid-2.6.STABLE1,也就是说在Squid2.6STABLE1就已经完全实现了这个功能,那么2.6STABLE2应该没有问题,会不会是2.6STABLE2的BUG呢,查询了一下2.6系列的所有Changelog,没有提到此故障的信息。推断我们的故障要么由一个未知BUG导致,要么是自己配置不当。BUG的问题我无法确认,只能先从配置入手。


找来一份2.6STABLE2带的默认配置文件,搜索Vary,第一条:

# TAG: cache_vary

# Set to off to disable caching of Vary:in objects.

#

#Default:

# cache_vary on

难道我的配置文件是off不成?赶紧检查,发现还真是off,sign,原来就是这个问题折磨我,改成on,将Apache的Deflate配置启用,再观察内存对象,发现静态网页真的被缓存了!


郁闷了许久,终于可以松口气了。


过了一会儿,再查看Squid的状态,发现缓存命中率没有下降,稳定在94%左右。


也许Squid还有什么可挖掘的空间吧,改天接着折腾!


后记:Squid对Vary和Etag的支持属于2.6的一项主要改进,这一特性改进Squid对HTTP/1.1标准的支持。在将Squid升级至2.6之前,也看过他的Changelog,但当时并不明白Vary到底有什么用途,这么一折腾,明白了不少。看来应该把HTTP/1.1的标准再好好研读一下。