关闭

Squid缓存命中率调整惨痛教训

标签: apachecachingcacheheaderiis测试
2613人阅读 评论(0) 收藏 举报
分类:
原贴:http://lwfs.net/2006/12/07/113/

Squid缓存命中率调整惨痛教训

公司的网站使用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的标准再好好 研读一下。


3 Responses to “Squid缓存命中率调整惨痛教训”  

  1. 1 PINE

    这是困扰我很久的问题,看了您的文章,受益匪浅。
    不过经过尝试,我的问题仍未结果,我的情况是:
    用SQUID 2.6 STABLE6 代理 启动了gzip的IIS
    现象是,SQUID可以缓村GZIP文件,但是GZIP的效果经过SQUID以后消失了。。。。
    IIS header如下:
    Content-Encoding gzip
    Server Microsoft-IIS/6.0
    Transfer-Encoding chunked
    Vary Accept-Encoding
    发现IIS与apache的gzip不同,会发出一个Transfer-Encoding chunked的header
    貌似SQUID不支持这个。。。

    希望一起讨论一下,谢谢

  2. 2 Adun Gaos

    IIS用的少啊,不方便发表什么看法,如果你有什么进展,一起分享啊

  3. 3 zsg

    adungaos的理解非常深入。我转载你的blog了。
    http://forrestrun.blog.sohu.com/29744931.html

Leave a Reply



 

 
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3159232次
    • 积分:33210
    • 等级:
    • 排名:第146名
    • 原创:76篇
    • 转载:1209篇
    • 译文:0篇
    • 评论:200条
    最新评论
    牛逼的网站