fastcgi_cache 总结
一 、调研过程：
选择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
| cache 前 | 50ms |
| cache后 | 0 ～20ms |
相比较，响应时间 缩减了 最低60 %
| cache 前 | 60ms |
| cache后 | 20ms ～ 30ms |
以上都是根据C端机器 进行的分析。
