缓存是我长期以来一直忽略的东西，因为我从事的项目是在本地 Intranet 上进行的，活动很少。我现在正在处理一个更大的 Rails 3 个人项目，我正在尝试找出应该缓存什么以及何时缓存。
Ruby on Rails 指南很好地解释了 Rails 3 中缓存的工作原理，但我无法理解与之相关的决策过程。
【问题讨论】：
标签： ruby-on-rails caching
永远不要为了它而缓存，因为有需要而缓存（除了主页之类的东西，你知道它会非常受欢迎。）启动网站，然后解析你的日志或使用NewRelic 之类的东西来看看什么是慢的。从那里，您可以找出值得缓存的内容。
不过，一般来说，如果某事需要 500 毫秒才能完成，您应该缓存，如果超过 1 秒，您可能在请求中执行了太多操作，您应该将正在执行的任何操作放到后台进程中……因为例如，获取 Twitter 提要或处理图像。
编辑：See apneadiving's answer too，他链接到一些很棒的截屏视频（尽管基于 Rails 2，但理论是一样的。）
【讨论】：
您需要考虑缓存几种内容：
缓存的另一面不应该不提，就是过期。它也往往是更难的部分。您必须知道缓存何时不再有效，并将其清除，以便生成新的内容。清道夫或观察者，取决于你如何实现你的缓存可以帮助你。您也可以仅根据时间值执行此操作，允许缓存具有 max-age 并在此之后清除它们，无论如何。
至于片段缓存与整页缓存，请根据这些部分的更新频率来考虑。如果一个页面的 3 个部分永远不会更新，其中一个是，也许你想缓存这 3 个，并允许实时获取那个 1，这样你就可以达到第二个精度。或者如果页面的不同部分应该有不同的缓存规则：也许“时间线”部分被缓存，但缓存时间为 1 分钟。而“朋友”部分缓存 12 小时。
希望这会有所帮助！
【讨论】：
如果网站的活动相对较少，则不应缓存任何页面。你缓存是因为性能问题，而性能问题是因为你有太多的数据要查询，太多的用户，或者更糟糕的是，这两种情况同时发生。
在您考虑缓存之前，您要做的第一件事就是查看您的应用程序中占用最多时间的请求。不是最慢的请求，而是您的应用程序花费最多总时间执行的请求。也就是说，如果您有一个在 1500 毫秒运行 10 次的请求 A 和在 250 毫秒运行 5000 次的请求 B，那么您首先要优化 B。
实际上很容易通过production.loggrep 提取呈现时间和 URL 以将它们组合成一个简单的报告。如果需要，您甚至可以实时执行此操作。
一旦您确定了有问题的请求，您就可以开始分析它为处理该请求所做的工作。第一件事是寻找任何可以通过使用预先加载或进一步预测您需要什么来组合的查询。接下来是确保您没有加载未使用的数据。
很多时候你会看到列出用户的代码，它会加载每人 50KB 的传记数据、他们的 Facebook 和 Twitter 句柄，以及关于他们的所有内容，而你使用的只是他们的名字。
尽可能少地获取，并以最有效的方式获取。不需要模型时使用connection.select_rows。
下一步是查看您正在运行的查询类型，以及它们表现不佳的原因。确保您的索引都设置正确并且正在使用中。检查您是否在执行复杂的JOIN 操作，这些操作可以通过一些战术反规范化来解决。
查看您在应用程序中存储的数据，并尝试找到可以从生产数据库中删除并存储在其他地方的数据。当数据不再相关时，定期循环出数据，如果需要，将其保存在单独的数据库中。
然后去看看你的数据库服务器是如何调整的。它有足够大的缓冲区吗？它是在可以以名义成本升级更多内存的硬件上吗？太多的人正在运行一个完全未经调整的数据库服务器，通过一些简单的设置，他们可以获得十倍的性能提升。
如果且仅当此时您仍然存在性能问题，那么您可能需要考虑缓存。
你知道为什么不先缓存吗？这是因为一旦你缓存了一些东西，缓存的数据就会立即过时。如果您的应用程序的某些部分在假设它始终是最新的情况下使用此数据，那么您将遇到问题。如果在数据确实发生变化时你没有使这个缓存过期，你就会遇到问题。如果您缓存数据并且不再使用它，那么您只是堵塞了缓存，您将遇到问题。基本上你在使用缓存的时候会遇到很多问题，所以通常是不得已而为之。
【讨论】：