fastcgi_cache 总结

标签：一个   区分   tle   ups   color   接口   没有   images   text   

一 、调研过程：

选择fastcgi_cache 做页面缓存之前，选定了ngx_srcache ， lua-resty-cache  和 fastcgi_cache这三个做对比 ，ngx_srcache ， lua-resty-cache  这两个是lua 写的nginx 扩展（都是upstream 到redis 进行存储）。可能是走网络存储的原因，lua版的在Jmeter压测后，TPS 达到 400/sec就上不去了。而fastcgi_cache则在1000／sec 浮动。

这三个cache 都有一个我们比较棘手的问题，就是cookie管理问题。（fastcgi_cache，ngx_srcache 会缓存住response的set-cookie ，而 lua-resty-cache则会清空）。想到的解决方案：

1、开始想的解决方案，把需要种的Cookie 用独立的接口封装起来，当nginx 接收到请求的时候，用lua的ngx.location.capture 同步发起subrequest ，同步返回。初步实践后，发现效果不尽人意。所以放弃了

2、通过js 异步去请求cookie 接口。但是这无疑又引来了新的请求。

老板们说马上打广告了，流量会飞涨。基于性能上和时间上的考虑，我们决定选择了fastcgi_cache这个来解决燃眉之急。 所以，我们目前只选择了首页和详情页，这两个目前并不太关心cookie的页面进行缓存。目前只缓存5min。

eg;  xxx

二、遇到的问题：

在过程中，由于对C端代码了解不多，只区分了pc 和wap ，并没有区分wap 和app的，所以造成第一次上一台机器的时候发现，wap 和app有样式冲突。后来在nginx 配置里进行了区分。

      三、原理和缓存策略可见wiki:

          看上一篇

      四、前后数据对比：

根据分析nginx access log统计， 命中概率： 缓存请求 ／ 请求总量 = 39% 左右。因为异步请求的接口访问量太大。所以造成负载的降低并不是太明显。

所以只从响应时间的维度来分析：

       1、具体接口的响应时间：

           首页www/fyc

            相比较，响应时间 缩减了 最低60 %

如下图：

 

 

fastcgi_cache 总结

标签：一个   区分   tle   ups   color   接口   没有   images   text   

原文地址：http://www.cnblogs.com/qlchan/p/7722797.html