关于Squid缓存命中率 一则

qweewq123qwe

Squid缓存命中率调整惨痛教训
<!-- The following two sections are for a noteworthy plugin currently in alpha. They'll get cleaned up and integrated better -->Published 十二月 7th, 2006 in System
http://www.lwfs.net/2006/12/07/113/
　　公司的网站使用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的标准再好好研读一下。