关于Squid缓存命中率一则

左手的ㄟ右手 2022-09-18 04:56 146阅读 0赞

### [**Squid****缓存**命中率调整惨痛教训][Squid] ###

Published 十二月 7th, 2006 in [System][]

[http://www.lwfs.net/2006/12/07/113/][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，也就是说在**Squid**2.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的标准再好好研读一下。

[Squid]: http://lwfs.net/2006/12/07/113/
[System]: http://lwfs.net/category/system/
[http_www.lwfs.net_2006_12_07_113]: http://www.lwfs.net/2006/12/07/113/