自动重建缓存
我运行一个包含大量数据的 Symfony 1.4 项目。主页和类别页面使用寻呼机，需要知道有多少行可用。我正在传递一个包含寻呼机联接的查询，这会导致这些页面的加载时间为 1 分钟。
我为相应的操作配置了cache.yml。但我认为解决方法是不够的，这是我的假设：
Symfony 在用户发出的单个请求中重建缓存。为了简化起见，我们将该用户称为“缓存受害者”。
在我们的例子中，数据需要及时更新 - 10 分钟的生命周期就足够了。显然，如果没有用户愿意成为“缓存受害者”，则缓存不会被重建，因此只是取消请求。这些假设正确吗？
所以，我想出了这个想法： Symfony 应该在重建缓存后伪造 http 请求。新的缓存条目应写入临时文件/目录，并在缓存重建完成后立即与以前的缓存条目交换。
这可能吗？
在我看来，这类似于双缓冲的概念。
如果多人游戏中只有一个“GPU 受害者”看到屏幕逐行构建，这不是很愚蠢吗？ （这是一个不平衡的比较，我知道......;））
编辑
没有“缓存受害者” - 每 10 分钟页面重新加载每个用户需要 1 分钟。
I run a Symfony 1.4 project with very large amount of data. The main page and category pages are using pagers which need to know how much rows are available. I'm passing a query which contains joins to the pager which leads to a loading-time of 1 minute on these pages.
I configured cache.yml for the respective actions. But I think the workaround is insufficient and here are my assumptions:
Symfony rebuilds the cache within a single request which is made by a user. Let's call this user "cache-victim" to simplify things.
In our case, the data needs to be up-to-update - a lifetime of 10 minutes would be sufficient. Obviously, the cache won't be rebuilt, if no user is willing to be the "cache-victim" and therefore just cancels the request. Are these assumptions correct?
So, I came up with this idea:
Symfony should fake the http-request after rebuilding the cache. The new cache-entries should be written on a temporary file/directory and should be swapped with the previous cache-entries, as soon as cache rebuilding has finished.
Is this possible?
In my opinion, this is similar to the concept of double buffering.
Wouldn't it be silly, if there was a single "gpu-victim" in a multiplayer game who sees the screen building up line by line? (This is a lop-sided comparison, I know ... ;) )
Edit
There is no "cache-victim" - Every 10 minutes page reloading takes 1 minute for every user.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为你的问题是由于一些缺失或错误的索引造成的。我有一个大型足球网站的 sf1.4 项目（即 200 万页/天），即使我们的数据库现在有超过 100 万行，寻呼机的速度也不会那么慢。使用 EXPLAIN 查看您的查询并检查哪里出错了......
I think your problem is due to some missing or wrong indexes. I've a sf1.4 project for a large soccer site (i.e. 2M pages/day) and pagers aren't going so slow even if our database has more than 1M rows these days. Take a look at your query with EXPLAIN and check where it is going bad...
抱歉，死灵术（有徽章吗？）。
通过配置cache.yml，您只是缓存应用程序的视图层（即css、js 和html）以用于不带参数的请求。导航寻呼机显然在 GET 请求上有一个 ?page=X 。
取自 symfony 1.4 config.yml 文档：
可能对你有帮助的是缓存数据库结果，但在 symfony/doctrine 上这是一个痛苦的过程。参考：
http://www.symfony-project.org/more-with-symfony/1_4/en/08-Advanced-Doctrine-Usage#chapter_08_using_doctrine_result_caching
编辑：
这也可能对您有帮助：
http://www.zalas.eu/symfony-meets-apc-alternative -php-缓存
Sorry for necromancing (is there a badge for that?).
By configuring cache.yml you are just caching the view layer of your app (that is, css, js and html) for REQUESTS WITHOUT PARAMETERS. Navigating the pager obviously has a ?page=X on the GET request.
Taken from symfony 1.4 config.yml documentation:
What might help you is to cache the database results, but its a painful process on symfony/doctrine. Refer to:
http://www.symfony-project.org/more-with-symfony/1_4/en/08-Advanced-Doctrine-Usage#chapter_08_using_doctrine_result_caching
Edit:
This might help you as well:
http://www.zalas.eu/symfony-meets-apc-alternative-php-cache