Rails Cache

Rails提供三种页面cache方式：

action cache静态化action的结果但不会跳过filter，使用简单，麻烦最少，提速不多，一般够用。成批expire可以通过expire_fragment

fragment cache用来静态化页面的一部分。这种cache是非常基础的，被action cache在内部使用。默认使用文件系统做store，足够快，也可以改成memcache store。

完全把页面静态化的page cache能提速几十倍，效果极其明显。缺点也很明显：跳过任何filter, 无法控制访问权限。一个额外的好处是因为实际跳过了整个Rails，所以间接减少了FCGI进程数量的需求。成批expire最好在文件系统中直接删目录。

对于page cache来说，如果只有少量需要动态获取的内容，可以使用js做点变通免得这丁点部分成为瓶颈。一种办法是在window.onload的时候让js去读cookie然后再显示内容, 这个显然有安全问题。改良的办法是通过AJAX从服务器lazy load进动态部分而不拖静态部分的后腿。当然这种办法也只适合需要少量动态获取的部分，否则就没有意义了。注意page cache因为跳过了filter(实际跳过整个Rails), 所以编码方式也不能靠Rails来控制，需要设置一下web server的mime类型编码(by 老友Simon Lei)。 此外page cache是很不安全的，应避免任何需要权限的内容被page cache掉。最后在集群环境，为了避免节点cache同步问题，不得不放弃使用page cache :(

url参数默认是被action cache和page cache忽略的。以前有个插件可以让action cache把url参数当cache key的一部分，不过1.1.5 routing代码改过之后没用了。我以前不理解，现在总算明白了为什么core team不实现这个功能，因为就算url参数当cache key对action cache是方便，但是对page cache就麻烦了，因为page cache完全是web server负责的，需要自己配web server url重写规则，这过分复杂了, 又依赖于特定web server。还是直接配rails routing简单有效。

通常页面cache已经足够快了，但是它节约的是erb的渲染时间。在数据层，通过memcache缓存复杂的计算结果，耗时的数据查询，session读写也是很有用的。基于memcache－client库的cached_model对简单的AR查询比AR默认的cache要好很多。默认cached_model会根据model名和记录id自动对单条记录cache 15分种，对复杂查询的结果需要手动cache。AR的update也会自动刷新cache,但是通过SQL update的得自己刷新cache。

最后，Lucas Lee兄说过有钱不如多砸到硬件上面节约优化时间是蛮正确的思路。如无必要(意思是profile出瓶颈在哪里）不要过早优化。cache设计方案很容易因业务逻辑变化而作废。