清单 10 显示了一种典型的配置，其中第一行 config.action_controller.perform_caching = true 将启用缓存。接下来的一行将准备缓存选项。注意，这里的诸多选项是为了让您可以获得更多的调试数据、禁用缓存和定义该缓存的名称空间。在 参考资料 部分给出的 memcached 站点可以找到有关配置选项的更多信息。
模型缓存
我们使用的最后一种缓存是基于模型的缓存。我们使用的是称为 CachedModel 的缓存插件的一种定制版本。模型缓存实际上是一种有限形式的数据库缓存。缓存很容易按模型启用。
要想让模型使用缓存解决方案，只需扩展 CachedModel 类，而非扩展 ActiveRecord，如清单 11 所示。 CachedModel 扩展 ActiveRecord::Base。ActiveRecord 并非全对象关系型映射层。此框架极大地依赖于 SQL 来执行复杂的特性，而且如果需要，用户可以很容易降至 SQL。直接使用 SQL 会使缓存出问题，因为缓存层必须处理完整的结果集，而不是单独一个数据库行。处理完整的结果集常常会问题不断，而且如果没有支持应用程序的深层逻辑，这几乎不太可能。正由于这个原因，CachedModel 的焦点才会放到缓存单个模型对象上，并只加速返回单行结果的查询。
清单 11. 使用 CachedModel
Class Cause < CachedModel
大多数 Rails 应用程序都会重复访问多个条目，例如用户对象。模型缓存在很多情况下都可以明显地使速度加快。对于 ChangingThePresent，我们刚刚开始加速基于模型的缓存。
结束语
Ruby 虽然是一门生产率极高的语言，但若从性能角度考虑，该语言解释性的特性让它并不那么理想。大多数主要的 Rails 应用程序都将会通过有效利用缓存来弥补某些不足。对于 ChangingThePresent.org，我们主要使用分段缓存，并通过控制器使用基于时间的方法来使缓存分段到期失效。这种方式很适合我们的网站，即使其中有一些页面会基于登录进来的用户有所变化。
我们还研究了使用受 memcached 支撑的 CachedModel 类所能带来的影响。虽然我们的研究还仅限于缓存对数据库性能所造成的影响，但早期的结果还是很有希望的。在 下一篇 文章中，我将介绍一些实用技巧，您可以使用这些技巧来为另一个真实世界中的 Rails 示例进行数据库优化。
