Rails 在开发人员中享有盛誉。Rails 一度备受瞩目，是业界争论的焦点。人们对它的评价也大相径庭：从一种高生产率技术到一个小玩意，从市场定位准确到宣传过度。与很多新技术一样，Rails 也被毫无例外地被打上了 “未经验证、可扩展性有限” 的标记。与 C 和 Java™ 语言不同，Ruby 是解释性的，且存在性能上的一些固有阻碍。

　　实际上，Internet 上的许多大型网站都使用的是解释性语言。这些网站均引入了类似 Ruby 所采用的相同的策略：即集群式的无共享的架构。此外，缓存也是必需的。要获得尽可能好的性能，许多站点都需要采用一种有效的缓存策略。Rails 开发人员也开始跟随其后。

　　几个场景

　　首先，让我先来带您浏览几个 ChangingThePresent.org 中的页面吧。我将显示站点中几个需要缓存的地方。然后，再指出我们为其中每个地方所做出的选择以及为实现这些页面所使用的代码或策略。尤其会重点讨论如下内容：

• 　　全静态页面
• 　　几乎无变化的全动态的页面
• 　　动态页面片段
• 　　应用程序数据

　　先来看看静态页面。几乎每个站点都会有静态页面，如图 1 所示，其中还有我们的条款和条件。可以通过单击 register 然后再选择是否接受用户协议来浏览相应页面。对于 ChangingThePresent 而言，我们从此页中删除了所有动态内容以便 Apache 能够对它进行缓存。按照我们 Apache 中配置的规则，这些内容永远都不会由 Rails 服务器生成。因此，我根本无需对其考虑 Rails 缓存。

图 1. 用户协议

　　接下来，再来看看全动态页面。理论上讲，ChangingThePresent 可以有一些动态构建的页面，但是这些页面一般很少变化。由于几乎所有页面都会显示用户是否登录，因此我们并不怎么关注这种缓存。