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设计方案很容易因业务逻辑变化而作废。

评论

7 楼 sorphi 2006-10-27  

对集群文件系统我也在学习当中，等实施过才知道：）

6 楼 cookoo 2006-10-26  

sorphi 写道

cookoo 写道

这本来就是rails的url重写方法。问题是怎么“只须删除”？如果是定期的设个cron刷新各节点还简单。如果是不定期刷新的，理论上需要一个同步程序，当一个节点的page cache刷新的时候去删掉其它节点的过期page cache。我从来没见过这样做的实例，不清楚这种方案会有什么问题或瓶颈。

这让我想到了现在流行的集中式cache方案memcached，调用者“只须失效”某个影响到的缓存即可，至于cluster环境中如何处理，则完全不必要关心。

对于page cache页面来说，如果某个业务方法的执行导致该page cache应当更新，那删除该页面的工作交由该业务方法来处理。至于删除本节点之后其他节点如何自动删除（同理：生成该节点中的page cache，其他节点自动生成），应当交给其他支撑技术来实现，比如集群文件系统。（我本人并未实施过，纯属纸上谈兵）

linux集群文件系统
http://linux.ccidnet.com/pub/html/tech/jiqun/index.htm

是啊，memcache怎么同步节点是透明的，所以现在Rails集群多用memcache当cache store，适合rails能控制的action cache和fragment cache. page cache的话，除非把web server配成能直接访问memcache（有没有这种方法未知）, 否则page cache就没法利用这种方式了。

集群文件系统完全不懂，应该比内存集群要慢得多巴？

5 楼 sorphi 2006-10-26  

cookoo 写道

这本来就是rails的url重写方法。问题是怎么“只须删除”？如果是定期的设个cron刷新各节点还简单。如果是不定期刷新的，理论上需要一个同步程序，当一个节点的page cache刷新的时候去删掉其它节点的过期page cache。我从来没见过这样做的实例，不清楚这种方案会有什么问题或瓶颈。

这让我想到了现在流行的集中式cache方案memcached，调用者“只须失效”某个影响到的缓存即可，至于cluster环境中如何处理，则完全不必要关心。

对于page cache页面来说，如果某个业务方法的执行导致该page cache应当更新，那删除该页面的工作交由该业务方法来处理。至于删除本节点之后其他节点如何自动删除（同理：生成该节点中的page cache，其他节点自动生成），应当交给其他支撑技术来实现，比如集群文件系统。（我本人并未实施过，纯属纸上谈兵）

linux集群文件系统
http://linux.ccidnet.com/pub/html/tech/jiqun/index.htm

4 楼 cookoo 2006-10-26  

sorphi 写道

配置url rewrite规则也挺好用，

引用

最后在集群环境，为了避免节点cache同步问题，不得不放弃使用page cache

实际是可以解决的：

http://www.kreny.com/docs/apache2.0/misc/rewriteguide.html

引用

空闲时间内的内容协商
说明:
这是一个很难解的功能：动态生成的静态页面，即，它应该作为静态页面发送(从文件系统中读出，然后直接发出去)，但是如果它丢失了，则由服务器动态生成。如此，可以静态地提供CGI生成的页面，除非有人(或者是一个cronjob)删除了这些静态页面，而且其内容可以得到更新。

方案:
以下规则集实现这个功能：
RewriteCond %{REQUEST_FILENAME}   !-s
RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]

这样，如果page.html不存在或者文件大小为null，则对page.html的请求会导致page.cgi的运行。其中奥妙在于，page.cgi是一个将输出写入page.html的(同时也写入STDOUT)的常规的CGI脚本，执行完毕，服务器则将page.html的内容发出。如果网管需要强制更新其内容，只须删除page.html即可(通常由一个cronjob完成)。

这本来就是rails的url重写方法。问题是怎么“只须删除”？如果是定期的设个cron刷新各节点还简单。如果是不定期刷新的，理论上需要一个同步程序，当一个节点的page cache刷新的时候去删掉其它节点的过期page cache。我从来没见过这样做的实例，不清楚这种方案会有什么问题或瓶颈。

3 楼 LucasLee 2006-10-25  

路过...突然发现楼主提到了我，荣幸,荣幸.

2 楼 sorphi 2006-10-25  

配置url rewrite规则也挺好用，

引用

最后在集群环境，为了避免节点cache同步问题，不得不放弃使用page cache

实际是可以解决的：

http://www.kreny.com/docs/apache2.0/misc/rewriteguide.html

引用

空闲时间内的内容协商
说明:
这是一个很难解的功能：动态生成的静态页面，即，它应该作为静态页面发送(从文件系统中读出，然后直接发出去)，但是如果它丢失了，则由服务器动态生成。如此，可以静态地提供CGI生成的页面，除非有人(或者是一个cronjob)删除了这些静态页面，而且其内容可以得到更新。

方案:
以下规则集实现这个功能：
RewriteCond %{REQUEST_FILENAME}   !-s
RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]

这样，如果page.html不存在或者文件大小为null，则对page.html的请求会导致page.cgi的运行。其中奥妙在于，page.cgi是一个将输出写入page.html的(同时也写入STDOUT)的常规的CGI脚本，执行完毕，服务器则将page.html的内容发出。如果网管需要强制更新其内容，只须删除page.html即可(通常由一个cronjob完成)。

1 楼 cookoo 2006-10-25  

没办法，草稿还算以前的时间，只好自己顶一下咯。