使与theme.json相关的缓存持久化

[弗利克索斯90]

这个他们_json缓存组当前是非持久的，这意味着即使站点使用持久对象缓存，该缓存组中的数据也只会被缓存在内部一个请求。换句话说，当一个函数在一个请求中被多次调用（至少多次调用）时，这种缓存只有好处。

不用说，我们在过去已经注意到解析主题.json运行相关的逻辑可能代价高昂，最好的结果是使这些缓存持久化，以便它们也可以在请求之外进行缓存。

最大的挑战是实现适当的缓存失效。最初，在Gutenberg中，缓存组是持久的，但由于以下原因导致了问题：

• 缓存失效很难确定（哪些事件会导致缓存的值过时？）
• 缓存逻辑（而不是数据库值）在WordPress中还不是一种常见的做法，其中一个怪癖是，当包含动作/过滤器钩子的逻辑被缓存时，它们可能不再运行，这可能会导致笨拙的开发人员体验

参见相关评论https://core.trac.wordpress.org/ticket/57648#评论：17

[弗利克索斯90]

此跟踪票据可能涉及古腾堡存储库中的几个问题和PR，以确定与以下内容相关的各种缓存使用的最佳方法主题.json和他们_json缓存组。

我希望我们至少可以在WordPress 6.3上取得一些显著的进展，所以我现在将在该版本中作为里程碑，尽管大多数工作都需要在Gutenberg存储库中进行，所以可能需要一段时间才能在这里获得PR。

抄送@oandregal@spacedmonkey

[iCaleb公司]

一种方法可以是只在前端请求期间使用持久缓存（在那里它可以获得最大的性能优势）。

每个登录的非ajax管理请求都可以至少一次获取theme.json。如果持久缓存中的内容发生了更改，则可以进行更新。作为备份（如果主题被更新但没有人登录），也可以在cron期间允许相同的无效检查。

最糟糕的情况是：没有cron在运行，也没有发生管理员端登录。在这种情况下，它只需要依赖TTL过期，前端请求必须重新填充缓存。

这提供了持久缓存的好处，同时以非常合理的方式解决了无效问题。

[奥安德雷格尔]

值得注意的是，这些缓存在古腾堡被实现为持久性的，为了阻止这项工作进入核心，它们被移除了。请参阅​https://github.com/WordPress/gutenberg/pull/46150详细信息，以及对话链接。公关也可以迅速恢复一切。

缓存失效涵盖了以下所有场景：

• upgrader_process_complete（升级过程完成）：用于WordPress、插件和主题更新。
• 切换主题（_theme）：活动主题已更改。
• 开始审阅主题：预览自定义程序和主题目录。
• 保存post_wp_global_styles：用户通过站点编辑器更新theme.json数据。
• 激活的插件和停用的插件：任何插件都可以连接到现有的主题.json过滤器，因此当它们被激活/停用时，过滤器可能会发生变化。

分歧具体体现在以下两点：

• 吸引消费者主题.json使用动态机制的数据（根据选项或用户元值决定是否挂接）。对于这些情况，替代方法是添加更多缓存无效点（选项add/update/delete等），或者要求使用者自己清除缓存。
• 不是通过常规WordPress机制进行的更新（FTP更新、通过git存储库管理的更新等）。另一种方法是要求消费者自己清除缓存。

注意这两种情况，只有当它们使用持久对象缓存插件时，默认情况下，作为核心的插件不会持久。

[spacedmonkey（空格键）]

WordPress核心已经有主题的缓存组。我想知道我们是否可以使用它们。这是一个特殊的缓存，它是持久的.​请参阅.

这意味着，对于拥有控制权的站点所有者，他们可以使该组持久化，因为他们可以在更新主题时清除缓存。否则，它是一个非持久组。这可能是一个值得效仿的有趣模型，因为它将允许生产站点使用托管公司知道不会更改的持久化模式，否则只是一个内存缓存。

[弗利克索斯90]

@iCaleb您的想法听起来确实很有趣，但仍有人担心这会对过滤器回调逻辑产生怎样的影响，因为过滤器来自生成数据的逻辑，然后将其缓存。无论何时返回缓存的数据，这些过滤器都不会运行。对于一些人来说，这可能是好的，但并不是意料之中的情况，而且随着WordPress的规模，我肯定会导致破坏。

因此，这里的问题是部分无效，部分过滤缓存时不再执行的逻辑（有关更多详细信息，请参阅@oandregal的注释）。

@spacedmonkey关于现有主题缓存组，我认为我们应该避免与之纠缠。该缓存组有不同的含义，并选择使其持久化可以这是个好主意。然而，如果您现在选择主题-json缓存组持久化，您将有效地选择破坏行为，而IMO不是我们应该提供或鼓励的。

[spacedmonkey（空格键）]

这个缓存也可以是全局缓存组，就像主题组一样。

[奥格勒克勒]

这是一个增强功能，在Beta 1发布之前的12天内，我们将不会向版本中添加新的增强功能，因此，由于没有补丁程序，我将把这个问题移到6.4。

[hellofrom托尼亚]

由于这张票可能涉及古腾堡的工作古腾堡（gutenberg-merge）用于跟踪的关键字。

这是对WP_主题_JSON_解析器，用于存储合并的WP_主题_JSON对象设置为静态属性，以避免通过从其他源合并来不必要地重新创建此对象。在我的测试中，这将此方法的执行时间减少了一半。

Trac票：https://core.trac.wordpress.org/ticket/57789

[乔麦吉尔]

在花了一些时间更好地了解这个系统并阅读了这个问题的历史之后，在我看来，我们应该重点关注一个策略，以便从WP_主题_JSON_解析器.

目前，这个类负责从四个不同的源（核心、块、主题和编辑器数据）加载theme.json数据，然后将它们合并在一起（取决于上下文）。

所有单独的源只计算一次并存储到该类的静态属性中，这很有帮助，但创建合并的WP_主题_JSON这个东西仍然很贵。

我想探索三种选择：

1. 将合并的数据存储到与各个源类似的静态属性中，以消除合并它们的成本。
2. 使整个合并结果可持久缓存
3. 如果无法持久缓存整个结果，则使每个源中的数据都可以持久缓存

选项1似乎是一个非常简单的优化，几乎没有负面影响。我已经打开了​公关作为概念的证明。

谢谢你用新鲜的眼光来看这个。

我想提供一个用例，说明这是如何中断的（但在大旅行箱)，这样我们可以讨论前进的道路。

• 将此修补程序应用于您的环境：

src/wp-content/themes/twentytht23/theme.json

@@ -323 +323 @@
                                }
                        },
 “核心/后内容”：{
+“颜色”：{
+“background”：“热粉红色”
+                               },
 “元素”：{
 “链接”：{
 “颜色”：{

src/wp-includes/blocks/archives.php

@@ -116 +116 @@
        );
 }
 add_action（'init'，'register_block_core_archives'）；
+
+添加操作（_A）(
+“初始化”，
+函数（）{
+WP_Theme_JSON_Resolver:：get_merged_data（）；
+       },
+0);
+文件末尾没有换行符

• 加载hello world帖子。预期结果是，文章内容使用热情的粉红作为背景色，如中所示大旅行箱:

在我看来，只要我们使获取合并缓存当注册的块不同时，为了避免将来出现问题，就像我们过去一样。

更长的大脑转储：

主题.json数据具有不同的生命周期和清理要求：

• 模板部件和自定义模板–在块注册之前（之前初始化)，并且它们的消毒不需要阻塞。
• 设置和样式–它们在块注册后被访问，并且需要清理块。

不知道这是错误和性能问题的根源。

WordPress 6.4引入了两种公共方法供用户访问​模板部件和​自定义模板，所以这种情况不太可能再次发生。然而！我仍然认为获取合并数据不应要求消费者知道WordPress生命周期中的_when_，可以安全地调用它以避免缓存问题。

哦！顺便说一句，@joemgill，我宁愿先在Gutenberg中进行这个更改，并且只在测试后将其移植到核心。这给了我们信心，它可以工作，并使同步两个代码库对每个人来说都更容易。

@oandregal，感谢您的关注和反馈。您在文章中解释的用例也通过失败的单元测试得到了确认。我可以看到，在几个不同的地方，theme.json数据是根据has_same_registered_blocks（）计算原点的方法，但尝试对合并数据使用类似的方法似乎不起作用（参见d1319a1）。

生命周期问题是我对这种方法的关注之一，这证实了这确实是一个问题。这也意味着任何依赖于WP_Theme_JSON_Resolver:：获取合并数据由于其返回值可能会根据应用程序生命周期中调用它的时间而更改，因此已经无法预测，因此实用程序功能级别的任何更高级别缓存也可能会导致类似的错误。

我不确定单元测试失败是因为在测试设置过程中缺少一个缓存应该失效的位置，还是有一种更可预测的方法来知道所有不同的数据源何时完成，此时缓存合并的对象是安全的。当然还有更多需要挖掘的地方。

一旦我们有了一个可行的方法，我很乐意尝试将这种变化的迭代应用于这个类的古腾堡版本。

我看到失败的测试是测试应该有条件地包括字体大小它测试了1）切换到经典主题和2）更新它声明的“主题支持”。这个获取主题数据方法不会缓存注入“主题支持”的完整结果：如果需要使用​重新计算最终主题数据。本周我没有太多时间帮助调试，我可以下周。希望这能有帮助吗？

@joemcgill我很喜欢这个过程，但是正如@oandregal上面提到的那样，为了解决悬而未决的问题，我们需要以某种方式缓存“主题数据”结果，以包括它们的数据带支架（_S）.

以前曾在中尝试过此操作#3624但最终关闭了。然而，回顾那里的讨论，虽然有一些复杂的问题需要解决，但我不认为有明确的原因关闭它，我认为当时我们只是没有优先考虑它。我确实认为该公关的想法值得一提，尤其是现在，因为它可能会带来更大的性能提升。

也许我们可以找到一个更好的解决方案来避免多次清理theme.json缓存的问题（请参阅​https://github.com/WordPress/WordPress-develop/pull/3624/files#diff-4112a9a0bb18713bc2fc7868ceffe4403d765722f605e42b313ef2cdc218177fR354-R356)? 我们可能会想出一些类似的东西WP_Theme_JSON_Resolver:：has_same_registered_blocks（）类似于检查主题支持数据是否与上次计算数据时发生更改的方法。

[乔麦吉尔]

现在重新分配给我自己，让它向前发展。

@oandregal我在这个PR上又做了一次尝试，看起来导致我们之前讨论的bug类型（和单元测试失败）的主要原因是，如果主题支持数据更改，则需要重新计算合并的数据。我修改了这个方法，使主题支持将数据保存到一个静态变量中，这样我们就可以测试值是否更改，就像测试注册的块是否更改一样。

这在减少页面生命周期中创建和合并的不必要的WP_Theme_JSON对象的数量方面带来了很大的改进，但不幸的是，我所能说的似乎并没有带来很大的性能优势，但我想做更多的分析。

在下面的两个XHProf报告中，您可以看到对各种theme.json数据源的所有getter方法调用的减少，以及对WP_Theme_JSON:：合并所有这些都会对内存和cpu使用产生积极影响，但只会略微减少总体服务器时间。

行李箱

公共关系

你认为这样的事情值得追求吗？

虽然复杂性使其进展复杂https://core.trac.wordpress.org/ticket/57789周围都是额外的过滤器主题.json解析，本PR探索了一种不受这种复杂性影响的方法：通过持久缓存主题.json文件（即没有以下解析），它已经在每次页面加载时节省了大量处理时间（对于使用持久对象缓存的站点）。

其影响已经相当显著wp-total公司TT1（经典主题）快8.9%，TT3（区块主题）快3.2%。另请参见​https://github.com/WordPress/gutenberg/issues/45616这是另一个相关的想法，它关注的是文件的JSON解码的成本，而仅仅是解码本身就有显著的负面性能影响。

本PR目前仅用于测试和基准测试。在并入核心之前，最好在古腾堡实施。不过，如果对这种方法有共识，我认为考虑到使用持久对象缓存对网站的性能影响显著，这对于WordPress 6.4来说仍然值得优先考虑。

请记住，这只有在使用持久对象缓存时才有影响。如果我们想给所有WordPress网站带来这些好处，我们可以考虑使用瞬态。

Trac票：https://core.trac.wordpress.org/ticket/57789

[弗利克索斯90]

我刚刚打开了上述公关​https://github.com/WordPress/WordPress-development/pull/5267前几天我的另一个想法是：虽然我们不容易缓存主题.json因为过滤器不会触发，所以我们可以很容易地缓存其中最底层的部分，即实际文件的JSON编码。

仅缓存该部分本身已经对使用持久对象缓存的站点的性能产生了显著的积极影响。请参阅公关描述了解更多内容。

如果对这个想法有共识，我很乐意将其移植到古腾堡公关。为了简单起见，我想首先在核心中实现它，这样我就可以在核心中对其进行基准测试。

[乔麦吉尔]

谢谢@flixos90。我同意我们应该在这里同时考虑这两种策略：

1. 以非持久方式缓存合并数据，以消除每次页面加载多次重新创建合并数据集的需要(​采购订单号5024)
2. 基于每个主题所需的不同无效规则，持久缓存每个主题数据源（核心、块、主题、用户）(​公关5267)

你能看一下最初的公关并从测试中提供反馈吗？我也会对你做同样的事。

@joemgill在我的基准测试中（类似于我用于#5267)，此PR显示出微小但持续的改进。在重新运行了几次之后，这个PR总是稍微快一点，所以我对做出这个改变感到很高兴。

供参考：

• wp-total公司TT3:PR时86.24ms，无PR时为86.6ms（速度快0.4%）
• wp-total公司TT1:52.1ms（带PR），52.24ms（不带）（快0.3%）

对我来说，对于给定的区块主题来说，收益略高也是有道理的主题.json在那里的依赖程度更高，我认为这在过去会导致更多昂贵的获取合并数据（）比经典主题更符合逻辑。

谢谢@felixantz。我将继续将这些更改应用于古腾堡公关，以获得该团队的反馈，并希望在核心更改之前在插件中测试这些更改。

@felixantz我已经应用了您的公关反馈，并在古腾堡回购中打开了这些更改的公关，如下所示：​https://github.com/WordPress/gutenberg/pull/54742

感谢@joemgill的反馈。

在我的测试中#5024，我注意到主题JSON处理期间最昂贵的操作是核心数据和用户数据，而块和主题的数据影响较小。

这当然是可能的。我只测试了整体性能，但没有分析。你能分享一下这4个不同过程花费了多少时间的数据吗？由于以下配置文件仅用于获取主题数据（）? 还有一个问题，你是用经典主题还是区块主题进行测试？询问，因为我希望获取主题数据（）仅对区块主题有影响。

我用这个公关做了一些个人资料，我没有看到你报道的那样的影响。在大多数情况下获取主题数据方法用于构造WP_主题_JSON_数据对象，它不受更改的影响。

我不太确定。当你说“未受影响”时，是指对性能影响很小吗？因为这里的变化肯定会影响获取主题数据（）当它读到主题.json文件。

我们可以在WP_Theme_JSON_Data对象传递给wp主题json数据主题过滤器，因为除非更新主题，否则不应更改，这可能有助于或进一步提高类构造函数的性能。

这可能行得通。您是否验证了在WP_主题_JSON_数据构造函数逻辑（它还实例化WP_主题_JSON)? 我只想接触正在读取的JSON文件部分，因为在这个部分中，我可以确定没有扩展点。

你能分享4个不同过程所花费的数据吗？

当然，抱歉，这意味着链接到我发布到票据的上一个配置文件，其中显示了的配置文件WP_Theme_JSON_Resolver:：get_merged_data（），它将所有单个getter显示为子进程。请参见：https://core.trac.wordpress.org/ticket/57789#评论：23

WordPress运行探查器的速度较慢。因此，JSON解码的成本似乎低于实际成本。

我理解你在这里的假设，但考虑到XHProf的设计方式，我不相信它是准确的。更可能的是，与我的系统相比，您的本地系统进行文件读取的时间有所不同。正如我们在分析时在其他地方看到的那样，文件I/O操作可以在性能结果中显示出更大的可变性。可能是因为操作码缓存或其他一些副作用，我没有再现那些操作花费很长时间的情况。

当你说“未受影响”时，是指对性能影响很小吗？

是的，“unfectiver”这个词用得不好。我的意思是，在针对主干的A/B测试中，我发现这种方法的性能影响几乎没有什么不同。

我将运行另一轮配置文件，看看是否可以验证相同的结果。

@乔麦吉尔说得对，我当然不想让我们的工作建立在假设的基础上。尽管如此，你能澄清一下你是如何准确地描述这一点的吗（哪个主题？启用了对象缓存？等等），并分享一个前后对比？您链接到的个人资料(https://core.trac.wordpress.org/ticket/57789#评论：23)似乎是另一位公关。

[乔麦吉尔]

@flixos90我在每一个PR上都运行了一轮服务器计时配置文件，虽然我看到两者都有了一些改进，但我不知道这是否足以在现阶段大力推动，但我宁愿看到这些更新通过Gutenberg插件进行测试，并应用于未来版本的WP。特别是，因为有一些主题JSON数据源我们还没有介绍。以下是我今天运行的数据的结果：

##行李箱###二十二点二十三分╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│232.64║╟─────────────────────┼────────────────────────╢║ 响应时间（第25页）│236.84║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│241.37║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│256.21║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│260.35║╚═════════════════════╧════════════════════════╝###二十、二十一╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│143.93║╟─────────────────────┼────────────────────────╢║ 响应时间（p25）│145.25║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│147.66║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│152.7║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│159.32║╚═════════════════════╧════════════════════════╝##公关5024###二十二点二十三分╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（第10页）╟─────────────────────┼────────────────────────╢║ 响应时间（p25）│230.65║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│233.19║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│262.33║╚═════════════════════╧════════════════════════╝###二十、二十一╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│142.86║╟─────────────────────┼────────────────────────╢║ 响应时间（p25）│143.73║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│144.72║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│147.78║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│156.58║╚═════════════════════╧════════════════════════╝##中继（带memcached）###二十二点二十三分╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│209.38║╟─────────────────────┼────────────────────────╢║ 响应时间（第25页）│210.3║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│212.58║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│221.22║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│234.26║╚═════════════════════╧════════════════════════╝###二十点二十分之一（带memcached）╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率←100%╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│127.66║╟─────────────────────┼────────────────────────╢║ 响应时间（p25）│128.61║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│129.73║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│131.87║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│138.06║╚═════════════════════╧════════════════════════╝##PR 5267（带memcached）###二十二点二十三分╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│206║╟─────────────────────┼────────────────────────╢║ 响应时间（第25页）╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│209.3║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│213.44║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）╚═════════════════════╧════════════════════════╝###二十点二十分之一（带memcached）╔═════════════════════╤════════════════════════╗║ URL│http://localhost:8889/ ║╟─────────────────────┼────────────────────────╢║ 成功率│100%║╟─────────────────────┼────────────────────────╢║ 响应时间（p10）│127.94║╟─────────────────────┼────────────────────────╢║ 响应时间（第25页）│129.12║╟─────────────────────┼────────────────────────╢║ 响应时间（p50）│132.8║╟─────────────────────┼────────────────────────╢║ 响应时间（p75）│139.86║╟─────────────────────┼────────────────────────╢║ 响应时间（p90）│143.62║╚═════════════════════╧════════════════════════╝

对于其中的每一个，我都从以下位置运行服务器计时CLI脚本​https://github.com/GoogleChromeLabs/wpp-research/tree/main/cli用50次跑步获得结果。

虽然两个PR似乎都有改善，但改善量通常在p25–p75量之间的方差范围内，因此很难说确切的预期改善程度。我现在将把这一点推到6.5里程碑，同时我们继续通过PR与古腾堡回购协议进行合作。

今天，我试图对所有这些用例进行另一轮分析，但看到了一些意想不到的结果，所以我计划在头脑清醒时再次运行它们。

此外，为了澄清您在上面提出的问题：

你链接到的个人资料(https://core.trac.wordpress.org/ticket/57789#评论：23)似乎是另一位公关。

我想说的是，如果你看一下树干的轮廓，你可以看到每个方法的相对壁面时间，这些方法可以获得特定原点的数据。即使在我最近的配置文件运行中，我始终看到核心和用户（即自定义）数据的生成时间最长。这两个似乎是通过缓存策略进行改进的最佳机会。

继续古腾堡公共关系的对话​https://github.com/WordPress/gutenberg/pull/554742#pullrequestreview-1654773700

@奥安德雷格尔

读取JSON文件已经产生了缓存数据，只是这个类中的静态变量。

如果我们想让它们在请求之间持久化，我想我们应该删除现有的缓存并使用wp_缓存_*而不是？实际上，它在预先存在的缓存数据上添加了_new_级别的缓存。

这些缓存并不相同：现在使用静态变量的缓存会缓存运行WordPress过滤器的数据，因此不应持久缓存，否则过滤器将无法运行。

我在这里提出的建议与此无关，因为读取JSON文件不会触发任何过滤器。这就是为什么这里提出的缓存可以是持久的，而现有的缓存不能。如果我们认为现有的静态变量缓存在这里添加的内容之上没有增加多少性能优势，我们可以考虑删除它们，但我不知道是否是这样，如果是这样的话，应该在另一个问题中进行探讨。

TL；DR这两种缓存方式是不可互换的。

我的另一个想法是：这些缓存的失效场景是什么？对于其他主题.json相关​缓存我们宣布无效​主题转换.

这里不需要您提到的示例中的无效化，因为建议的缓存是按主题操作的。换句话说，当前主题是哪个并不重要。由于版本更改，更新主题自然会依赖于不同的缓存。这里可能要添加的一件事是过期，以确保我们不会无限期地保留过时的主题版本缓存。

@乔麦吉尔你能继续回答我的问题吗​https://github.com/WordPress/WordPress-develop/pull/5267#问题评论-1733827722你什么时候有机会？我想更好地了解您用于配置文件的环境和配置。

这些缓存并不相同：现在使用静态变量的缓存会缓存运行WordPress过滤器的数据，因此不应持久缓存，否则过滤器将无法运行。

🤔 让我分享我所看到的：

• 我们已经有了诸如静态：：$theme_json_file_cache和静态：：$i18n_schemaJSON文件的内容（核心、主题和翻译模式）。在调用任何筛选器之前，都会填充这些缓存。它们是作为静态变量实现的，因此不能在请求之间持久化。
• 本公关介绍核心${wpversion},主题_${样式表}_${版本},i18n_schema${版本}与现有数据完全相同。尽管如此，它们是通过wp_缓存_*因此，它们可以被持久化。

我的问题是：为什么我们不删除静态：：$theme_json_file_cache和静态：$i18n_schema如果我们引入可以通过wp_缓存_*? 这有帮助吗？

这里不需要您提到的示例中的无效化，因为建议的缓存是按主题操作的。

这就是我看到的：

• 这个静态：$i18n_schema确实通过清除清除缓存数据在主题切换（过滤器）上执行切换主题（_theme）和开始审阅主题). 如果我们通过i18n_schema${版本}，为什么不清除它的非持久版本？

• 这个静态：：$theme_json_file_cache在任何时候都不会被清除。然而，相应的核心${wpversion}和主题_${样式表}_${版本}该公关引入的缓存将是持久的，因此它们更容易过时。我想我们应该回答的问题是：在任何情况下，版本都不会改变，但底层会改变吗主题.json做？

@oandregal谢谢你的澄清，现在我明白你的意思了。以前我考虑过静态变量缓存WP_主题_JSON实例（例如$核心,$块等变量）。但你是对的，我同意如果我们引入这种持久缓存机制，你提到的这两个静态变量就不会有任何额外的值，所以它们确实可以被删除。👍

[弗利克索斯90]

将其作为6.5里程碑的高度优先事项，部分原因是​https://github.com/WordPress/WordPress-develop/pull/5267对于使用持久对象缓存的站点。

我们需要验证这一点，但目前这是一种很有前途的方法，非常适合我们在6.5中继续追求的一般模板加载重点。

@oandregal输入​https://github.com/WordPress/WordPress-develop/pull/5267/commits/a7d99d78992e370ab130f1cec79475301909d161，我已经删除了您提到的属性，因为由于使用了WP缓存API，它们现在是多余的。

我实现了一个等效的Gutenberg pull请求​https://github.com/WordPress/gutenberg/pull/56095，准备进行审查，包括使用比较wp性能.

[乔麦吉尔]

回复乔麦吉尔:

重温我针对这个问题提出的最初探索：

我想探索三种选择：

1. 将合并的数据存储到与各个源类似的静态属性中，以消除合并它们的成本。

这一想法在​这位古腾堡公关它确实显示出了一些改进，我们可以将其作为一种微观优化进行合并和测试。

2. 使整个合并结果可持久缓存

为了使合并的数据能够持久缓存，需要对合并数据可能受到的每种影响方式进行无效处理。包括更新核心版本、切换或修改活动主题、更改注册块以及通过网站编辑器（或类似功能）更改用户编辑的设置。每个源（即核心、块、主题和用户）也可以被过滤，这使得持久缓存具有挑战性，除非我们只缓存预先过滤的值，而不是当前静态缓存的最终值。

3. 如果无法持久缓存整个结果，则使每个源中的数据都可以持久缓存

鉴于上述想法2的复杂性，我认为我们应该关注这个想法。

到目前为止，最贵的WP_主题_JSON计算的来源似乎是WP_Theme_JSON_Resolver:：get_Theme_data在表面上。因此，在那里实现缓存是有意义的，正如@flixos90在​这位古腾堡公关.

然而，这有点令人误解，因为此方法似乎是应用程序生命周期中第一个调用的方法。该方法由两者调用wp_get_theme_data_custom_templates和wp_get_theme_data_template_parts之前WP_Theme_JSON_Resolver:：获取合并数据。这意味着WP_Theme_JSON_Resolver:：get_Theme_data最终包括初始填写静态属性的成本WP_主题_JSON类，包括对WP_Theme_JSON:：get_blocks_metadata和WP_Theme_JSON:：清理，占处理时间的大部分。因此，在缓存WP_主题_JSON主题中的数据会有所帮助，但不会消除调用WP_主题_JSON构造函数，它只会将处理转移到其他地方。

尽管如此，我认为值得继续探索优化，以减少核心和主题数据的冗余处理。核心数据应该能够由WP版本持久缓存，类似于我们在中处理缓存的方式register_core_block_style_handles（）。对于特定于主题的数据，我们可能应该遵循#59719.

下一步，验证持久缓存WP_主题_JSON由核心和主题提供的数据，通过执行一个浅层实现并运行一组新的基准测试。

[乔麦吉尔]

将此向前推进，以便在下一版本中继续讨论/改进。

通过重用使与theme.json相关的缓存持久化缓存（_G）和缓存添加（_A）WP_Theme中的方法。这意味着缓存仅保存1800秒。由于以下原因，主题json的缓存无效。

• 调用WP_Theme:：cache_delete。在更新主题、编辑文件或删除主题时调用。
• 全球风格帖子已更新。
• 切换或预览主题。
• 像其他主题缓存一样，1800秒后失效。

Trac票：https://core.trac.wordpress.org/ticket/57789

[spacedmonkey（空格键）]

@flixos90@joemcgill我整理了我自己的​公共关系。这要简单得多。它可以很好地与其他主题缓存配合使用，这意味着在调用时，theme_json缓存将失效WP_Theme:：缓存删除.

我会喜欢你对我的公关的想法。

我要结束这个​相关的古腾堡公关考虑到这种方法没有提供足够大的可测量的性能影响。在未来，我认为如果我们能够将WP_主题_JSON数据持久化。

[乔麦吉尔]

我正在对这个问题进行一些清理，以便在6.6发布周期中取得更多进展。

@spacedmonkey，我回复了[你的公关​https://github.com/WordPress/WordPress-develop/pull/6289]在这样做的过程中，我意识到澄清这张罚单的目标可能会很有用。

此票据的目的不仅仅是将数据存储到当前他们_json缓存组持久化，但要解决到目前为止无法持久化数据的根本原因。

一般来说，我们将数据存储到他们_json缓存组是为了避免从WP_主题_JSON_解析器类，包括与访问和转换此合并对象的特定属性（设置、样式、自定义CSS等）相关的属性。这个WP_主题_JSON_解析器类负责合并在一起WP_主题_JSON数据来自4个来源（即“来源”）：核心、注册块、主题和站点编辑器中的用户自定义。理想情况下，我们可以持久缓存最终合并的WP_主题_JSON数据以及依赖于此合并数据的任何昂贵操作的结果。然而，处理每个源的缓存无效是复杂的，这是这项工作中的一个障碍。

为了向前推进，我们应该尝试在源代码级别处理持久性。来自每个源的数据已经存储在每个请求的静态属性中，但这些数据并没有以持久的方式缓存。我们应该能够基于WordPress版本持久地缓存来自“核心”源的数据。我们还可以根据主题的theme.json、父主题的theme.json和任何添加主题支持（）值。我认为我们现在应该关注这两个起源。

这个​之前的公关from@flixos90已经将重点放在了这两个来源上，但专门将缓存限制为仅读取和翻译theme.json文件。虽然这已经是一个改进，但我们应该验证该方法仍然具有与他报告的相同的影响，并看看是否可以通过缓存不仅仅是翻译的文件来增加影响。然而，我目前对这种方法有两个担忧：

1. 阅读和构建WP_主题_JSON对象用于构造和清理WP_主题_JSON对象本身。
2. 在衡量任何PR的影响时，我们应该谨慎，不要过分强调基于避免文件操作的性能提升，因为我们已经确定，在大多数情况下，文件读取最终都会缓存在OPcache级别。

我也关门了​我以前的公关考虑到它没有产生可测量的影响。

Trac票：#57789

57789的第1部分是看看我们是否可以通过缓存来提高性能获取预备数据.

在筛选之前缓存JSON只带来0.01%的好处

目前的主要回归来自WP_Theme_JSON_Data:：__construct和WP_Theme_JSON:：__construct

[kt12]

@乔麦吉尔基于你的评论​https://wordpress.slack.com/archives/C02KGN5K076/p1714752083294029我已经调查过了WP_Theme_JSON:：resolve_custom_css_format和WP_Theme_JSON:：remove_keys_not_in_schema.

这两个函数都涉及遍历整个树，并且都是递归执行的。

resolve_custom_css_格式非常简单，几乎没有改进的余地，因为必须访问所有树节点，递归似乎是最好的选择。

删除密钥非模式是有点复杂的实现，但我找不到简单的方法。我正在检查是否可以构建一些可以轻松删除密钥的启发式方法，但到目前为止还没有成功。

[第12章]

添加到前面的评论中-我确实试着看看是否缓存删除密钥非模式是否可以改善这种情况。
创建缓存密钥的成本是递归所需成本的数倍。所以缓存在这里不是一个解决方案。

这是我的实验-
​https://github.com/WordPress/WordPress-develop/pull/6583

[奥格勒克勒]

在Beta 1发布之前，我们还有3个小时的时间等待提交冻结，看起来这张票据不会及时进入Trunk。我正在重新安排到下一个里程碑。如果你正在努力工作，并且即将合并，请在准备好后将其返回。

Trac票：https://core.trac.wordpress.org/ticket/57789

@乔麦吉尔，门票的范围仍然在我们最初决定的范围内。我只是在持续缓存获取主题数据（）和获取预备数据（）核心的性能收益不到1%。

我的努力是为了维护wp_theme_json_data_default和wp主题json数据主题然而，大多数回归发生在静态返回和筛选器调用之间。值得注意的是，值现在在过滤器之后被静态缓存，以确保它们反映过滤器的任何更改。如果wp_theme_json_data_default和wp主题json数据主题用作纯过滤器，而不是用作操作。

一个解决方法是打电话wp_theme_json_data_default和wp主题json数据主题类似于从持久缓存初始化时的操作。这样，两个钩子都可以用于将其用作动作的人。当缓存过期时，过滤器版本将可用。

@乔麦吉尔，我已经用你的反馈更新了这个公关（我很快就会把它转到英国）。我看到我意外地按下了用于获取度量的“块”源缓存。我现在已经解决了这个问题。
现在，仅为添加了缓存主题_数据和核心数据.
在新的更新中，

• 我在过滤器之前创建了一个缓存，所以我甚至可以在缓存版本中添加过滤器。
• 删除了所有其他静态变量。
• 我保持了通常的有效期，最低为10分钟。我的主要目标是对所有缓存进行一次数据库调用，而不是多个具有不同到期日的数据库调用。

@此任务的joemgill GB问题-​https://github.com/WordPress/gutenberg/pull/62794

@乔麦吉尔，暂停。