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