自动重建缓存答案

【问题标题】：Automatically rebuild cache自动重建缓存
【发布时间】：2011-09-29 14:22:15
【问题描述】：

我运行一个包含大量数据的 Symfony 1.4 项目。主页和类别页面正在使用需要知道有多少行可用的寻呼机。我正在传递一个包含与寻呼机连接的查询，这导致这些页面的加载时间为 1 分钟。

我为相应的操作配置了 cache.yml。但我认为解决方法是不够的，这是我的假设：

Symfony 在用户发出的单个请求中重建缓存。让我们称这个用户为“缓存受害者”以简化事情。

在我们的例子中，数据需要不断更新 - 10 分钟的生命周期就足够了。显然，如果没有用户愿意成为“缓存受害者”并因此取消请求，则不会重建缓存。这些假设是否正确？

所以，我想出了这个主意： Symfony 应该在重建缓存后伪造 http-request。新的缓存条目应写入临时文件/目录，并在缓存重建完成后与之前的缓存条目交换。

这可能吗？

在我看来，这类似于双缓冲的概念。

如果多人游戏中只有一个“gpu 受害者”看到屏幕逐行堆积，这不是很傻吗？（这是一个不平衡的比较，我知道...... ;)）

编辑

没有“缓存受害者” - 每个用户每 10 分钟重新加载一次页面需要 1 分钟。

【问题讨论】：

坦率地说，我首先要研究为什么为寻呼机计算行数（如果我理解正确的话？）需要 1 分钟才能完成。无论哪种方式，要解决的明显问题是陈旧缓存的加载时间。其次，用户取消请求通常不会阻止网络服务器完成请求的运行（除非它超时或达到另一个限制）。
好的，那么“处理请求”将被取消。由于大量数据和连接，需要 1 分钟。寻呼机查询本身非常简单。寻呼机需要知道条目数，因为它会计算有多少页可用。
我建议你应该先解决这个问题，我看不出为什么填充寻呼机需要这么长时间的合理解释。我相信您可以对其进行优化，但在不了解具体细节的情况下无法进一步评论。
这不是正常行为，symfony 中的标准分页器类会根据您设置的页面大小添加限制，并对整个表执行额外的 COUNT() 查询。这两个查询都不应该花费 45 秒。您可能需要粘贴寻呼机的代码。
@Gerry 让我们continue this discussion in chat

【解决方案1】：

我认为您的问题是由于一些缺失或错误的索引造成的。我有一个大型足球网站的 sf1.4 项目（即 2M 页/天），即使我们的数据库现在有超过 1M 行，寻呼机也不会那么慢。用 EXPLAIN 查看您的查询并检查它哪里出错了......

【讨论】：

我尝试了 EXPLAIN 和优化的索引。我们升级了硬件，这让事情变得更好。然而，你没有回答我的问题。我问缓存交换的概念是否可行。为什么用户在构建新的缓存条目时必须等待？ - 旧的缓存条目仍然可用。
我不明白这一点。是的，缓存交换是可能的，但此解决方案仅适用于一些非常关键的场景。而且我认为您可以通过另一种方式处理您的数据库内容。

【解决方案2】：

对不起，死灵术（有徽章吗？）。通过配置 cache.yml，您只是在缓存应用程序的视图层（即 css、js 和 html）以用于不带参数的请求。导航寻呼机显然在 GET 请求上有一个 ?page=X。

取自 symfony 1.4 config.yml 文档：

无论配置如何，在查询字符串中带有 GET 参数或使用 POST、PUT 或 DELETE 方法提交的传入请求都不会被 symfony 缓存。 http://www.symfony-project.org/reference/1_4/en/09-Cache

可能对您有所帮助的是缓存数据库结果，但这对 symfony/doctrine 来说是一个痛苦的过程。参考： http://www.symfony-project.org/more-with-symfony/1_4/en/08-Advanced-Doctrine-Usage#chapter_08_using_doctrine_result_caching

【讨论】：