Magnolia“页面感知”缓存

Posted

技术标签:

【中文标题】Magnolia“页面感知”缓存【英文标题】:Magnolia "Page Aware" Caching 【发布时间】:2019-12-12 11:36:08 【问题描述】:

我正在使用 Magnolia v5.7.1 并且刚刚配置了 advanced cache module for site aware caching。在此之前,默认行为是在工作区中有任何(激活、导入、编辑)的情况下刷新所有缓存。使用高级缓存模块,如果特定站点上的任何内容发生更改,则仅刷新相应的缓存。到目前为止,一切顺利。

现在,假设页面 A 和 B 被缓存。如果页面 A 被更改,这将刷新页面 A B 的缓存(只要两个页面都在同一个站点上)。我想知道默认行为不是以下内容是否有充分的理由:如果页面 A 发生更改,页面 A 的缓存会被刷新。

我知道实现我自己的FlushPolicy 是可能的,但是,这似乎是一项艰巨的任务,也许我错过了一个不能完成“页面感知”缓存的充分理由。

【问题讨论】:

【参考方案1】:

刷新所有页面的充分理由是一页的更改可能会影响其他页面。例如,这很常见。从页面结构生成菜单,因此重命名一页会影响所有显示菜单的页面。或者例如。在一个页面中有一个teaser 组件,它将从它正在戏弄的页面中获取抽象文本和图像。等等。简而言之,如果不计算依赖图,系统就无法知道哪些页面渲染可能会受到其他页面更改的影响。在某些情况下,几乎不可能知道。想象一下事件日历页面,每个事件都有子页面。日历由搜索当月所有事件的查询组成。由于涉及到动态查询,计算依赖图变得更加复杂。 也就是说,仍然可以计算依赖关系并仅刷新受影响的页面,但实际上,在大多数情况下,计算此类图的工作量(cpu 时间)比简单地刷新所有页面并重新渲染页面要大,因为渲染很便宜(特殊情况除外)。最重要的是,删除缓存中的所有项目也比逐个检索它们并仅刷新那些需要刷新的项目要快得多。

TLDR;对于大多数网站来说,尝试进行非常智能的页面缓存管理是不值得的,因为成本大于收益,而不会真正影响性能。

【讨论】:

以上是关于Magnolia“页面感知”缓存的主要内容,如果未能解决你的问题,请参考以下文章

Magnolia 页面模板未注册

基于子页面的 Magnolia 菜单项

父页面属性 magnolia

获取 magnolia 中组件的父页面节点

Magnolia 防止使用父页面模板创建子页面

营销标签未在 Magnolia 页面中呈现内容