在我目前的项目（Rails 2.3）中，我们收集了120万个关键字，每个关键字都与一个着陆页相关联，这实际上是给定关键字的搜索结果页。这些页面中的每一页都非常复杂，因此生成可能需要很长时间（在适度负载下最多2秒，在流量峰值期间，使用当前硬件时甚至更长）。问题是，99.9％的访问这些页面是新访问（通过搜索引擎），因此在第一次访问时缓存它并没有多大帮助：访问仍然很慢，下一次访问可能几个星期后。
我真的很想让这些页面更快，但我对如何做到这一点没有太多的想法。想到的一些事情：
预先为所有关键字构建缓存（使用非常长的TTL，一个月左右）。但是，构建和维护此缓存可能会非常痛苦，页面上的搜索结果可能已过时，甚至无法再访问;
鉴于此数据的易变性，请勿尝试缓存任何内容，只是尝试向外扩展以跟上流量。
我真的很感激有关这个问题的任何反馈。
答案 0 :(得分：1)
有些东西并没有从你的描述中加起来。当你说99.9％是新访问时，这实际上是非常不重要的。当您缓存页面时，您不仅仅是为一个访问者缓存它。但也许你会说，对于这些页面的99.9％，每隔几周只有一次点击。或者你的意思是99.9％的访问是针对一个很少被点击的页面？
在任何情况下，我首先想知道的是，是否有相当大比例的页面可以从整页缓存中受益？是什么将页面定义为受益于缓存？那么，命中与更新的比率是那里最重要的指标。例如，即使每天只被点击一次的页面也可以从缓存中获益，如果它只需要每年更新一次。
在许多情况下，页面缓存无法做很多事情，因此您需要深入了解更具体的内容。首先，对页面进行概要分析......生成的最慢部分是什么？哪些部分有最频繁的更新？是否有任何部分依赖于用户的登录状态（听起来不像你有用户？）？
最低悬的水果（以及将在整个系统中传播的东西）是良好的老式优化。为什么生成页面需要2秒？优化代码和数据存储的地狱。但是不要像删除所有Rails帮助程序那样无所事事。始终首先进行概要分析（NewRelic Silver and Gold对于从实际生产环境中获取跟踪非常有用。绝对值得花费）优化数据存储。这可能是通过非规范化或在极端情况下通过切换到不同的DB技术。
完成所有合理的直接优化策略后，请查看片段缓存。最常访问的页面中最昂贵的部分是否可以缓存具有良好的命中更新率？警惕复杂或需要昂贵维护的解决方案。
如果有任何基本规则来优化可扩展性成本，那么您需要足够的RAM来满足您需要定期提供的所有内容，因为无论您尝试多么聪明，这将始终为您提供比磁盘访问更多的吞吐量关于它。 RAM需要多少钱？好吧，我在极端规模上没有很多经验，但如果你有任何磁盘IO争用，那么你肯定需要更多的RAM。你想要的最后一件事是IO争用一些应该快速的东西（即记录），因为你正在等待一堆可能在RAM（页面数据）中的东西。
最后一点说明。所有可扩展性实际上都是关于缓存（CPU寄存器＆gt; L1缓存＆gt; L2缓存＆gt; RAM＆gt; SSD驱动器＆gt;光盘驱动器＆gt;网络存储）。这只是一个谷物问题。页面缓存非常粗糙，简单易用，如果可以的话，可以轻松扩展。但是，对于大型数据集（Google）或高度个性化的内容（Facebook），缓存必须在更精细的级别上进行。在Facebook的情况下，他们必须优化到不可用的资产。从本质上讲，他们需要做到这一点，以便可以在几毫秒内从数据中心的任何地方访问任何数据。每个页面都是为具有自定义资产列表的单个用户单独构建的。这一切都必须放在＆lt; 500毫秒。