Performance 自动重建缓存

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

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

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

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

所以，我想到了这个主意： Symfony应该在重建缓存后伪造http请求。新缓存项应写入临时文件/目录，并在缓存重建完成后立即与以前的缓存项交换

这可能吗

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

如果在多人游戏中有一个“gpu受害者”看到屏幕一行一行地堆积起来，这不是很愚蠢吗？（我知道，这是一个不平衡的比较…））

编辑

---

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

我认为您的问题是由于缺少或错误的索引。我有一个大型足球网站的sf1.4项目（即每天200万页），即使现在我们的数据库中有超过100万行，寻呼机的速度也不会太慢。请使用“解释”查看您的查询，并检查哪里出了问题…

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

摘自symfony 1.4 config.yml文档：

无论配置如何，symfony都不会缓存查询字符串中包含GET参数或随POST、PUT或DELETE方法提交的传入请求

也许可以帮助您缓存数据库结果，但在symfony/doctor上这是一个痛苦的过程。参考：

编辑： 这也可能对您有所帮助：

---

坦率地说，我首先想了解一下为什么一个寻呼机的行数（如果我理解正确的话？）需要1分钟才能完成。无论哪种方式，要解决的明显问题都是陈旧缓存的加载时间。其次，用户取消请求通常不会阻止Web服务器完成请求的运行（除非超时或达到另一个限制）。好的，那么“处理请求”将被取消。由于数据和连接量很大，需要1分钟。寻呼机查询本身非常简单。寻呼机需要知道条目数，因为它会计算可用页面的数量。我建议您首先处理这个问题，我看不到一个合理的解释来解释为什么填充寻呼机需要那么长的时间。我相信您可以对其进行优化，但在不了解详细信息的情况下不能进一步评论。这不是正常行为，symfony中的标准pager类会根据您设置的页面大小添加一个限制，并对整个表执行额外的COUNT（）查询。这两个查询都不应使用45。您可能想粘贴寻呼机的代码。@Gerry让我们用解释和优化索引尝试一下。我们升级了硬件，这让事情变得更好。然而，你没有回答我的问题。我问缓存交换的概念是否可行。为什么用户在生成新缓存项时必须等待？-旧的缓存条目仍然可用。我看不出有什么意义。是的，缓存交换是可能的，但此解决方案仅适用于某些非常关键的场景。我认为你可以用另一种方法解决这个问题，用你的数据库。