目前正在一个专用的虚拟机上进行一些深入的测试，看看我们如何减少差异并为测试结果带来一些一致性。

共享这个松懈的线程此处显示可见性。

• GitHub Actions工作人员似乎没有产生足够一致的结果。
• 然而，在本地运行工作流是不可复制的，因此这也不是一个解决方案。（此外，它本身的数据一致性似乎也没有那么好。）
• @dmsnell公司一直在计算机集群中进行基准测试，并在此概述了他的方法：https://fluffyandflakey.blog/202/10/20/profiling-wordpress-v1/
• @瑞士风格还在专用虚拟机中进行基准测试。
• 这项研究的结果应该会影响整个基准测试工具，即WP核心自动化性能测试、我们正在进行的额外的发布到发布基准测试，以及WordPress插件可以使用的可重用测试环境（参见可重用性能测试环境 #852).

需要回答两个非常高级别的问题：

• 我们能否确定一个既可重用又能产生一致结果的工作流（例如，测试完全相同的WordPress版本/代码库时，差异小于5%）？
• 如果没有，或者另外，我们是否可以使用统计方法来稳定指标，尽管它们存在差异，例如使基准仪表盘更有帮助？

啊，太棒了，还没看到那个帖子👍
看起来我们正在做类似的事情，虽然我也在看网络重要信息，以及更好的重置、网络节流等。但不幸的是，没有R😅

最终，我认为如果我们想要尽可能准确的话，我们将无法使用适当的统计方法。

GitHub Actions工作人员似乎没有产生足够一致的结果。

我花了大量时间在古腾堡的GitHub Actions上，总的来说，根据我们所做的所有测试，它比我预期的要可靠。也就是说，我们在性能测试方面遇到的所有问题都在Gutenberg测试运行程序中得到了解决，而不是通过跳转GitHub Actions。

我猜这在Core中会更加困难，因为我认为有证据表明，在测试“小”时，我们应该至少运行测试几个小时，然后才能得出结论，GitHub Actions的截止时间为六个小时。不过，我想知道是什么让我们不信任它？

我们还可以讨论更多问题吗？我怀疑我们在GitHub Actions上看到的一些问题存在于每个测试环境中，即使是最孤立和最受控制的环境。

对完全相同的WordPress站点运行两次基准测试应该会产生完全相同的加载时间指标

我想同意这一点，并注意到主要的警告，我们在Core中通常有不同的运行时模式，这些模式基于已经处理或未处理的特定计算和缓存。例如，一个网站会快速下载插件版本列表以进行更新，这会减慢一个或多个早期请求的速度，我们可以禁用此行为和所有瞬态行为，但是，为了在报告的数字中建立稳定性，我们会故意忽略那些对性能有实际和可测量影响的东西。

我们可以从基准中强制获得相同的结果，但仍然会偏离目标。我认为我们可以用另一种方式来谈论您的目标，即尽可能消除基准中的外部偏差.

在寻求消除测试中的可变性时，我们很可能会发现Core中存在的问题。这里的一种可能性是发现性能优化本身可以使平均请求更快，但有时会使请求更慢。

我们可能无法消除可变性，因为它可能是代码中固有的（可能是像MySQL那样间接执行维护工作，这与WordPress无关，但与此相关的是，它在部署的世界中“在那里”发生，WordPres对影响站点的事情有某种反应）。我们可以能够开始识别代表这些不同代码路径的集群，并尝试分别对它们进行基准测试，以了解它们的行为，或者研究消除集群并重新统一运行时性能的方法。

以故意忽略最坏的性能问题为代价，如果我们还没有开始的话，一种方法是在报告任何指标之前忽略数据中的异常值。如果我们在进行过程中更新度量，例如平均值，那么这是不可能发生的。在计算合计度量之前，我们需要获得每个样本，以便确定给定的样本是否为异常值。（我说的是“离群值”，但大多数情况下，我认为其中许多页面呈现速度要慢得多，因为它们比大多数请求要做更多的工作）。

再进一步，我们总是可以公开原始数据以供进一步审查。我在古腾堡做过几次这样的工作，我们可以将原始数据保存为CI性能测试运行中的工件，此外还可以报告PR的平均值和增量。通常，该工件会被忽略，但当您在测试运行中发现一些令人惊讶的东西时，使用它会非常有用。

我正在寻找一个大型且具有代表性的复杂网站。空荡荡的测试场地是如此不切实际，以至于这些数字并不意味着太多。这就像比较一个函数的不同实现来计算字符串中的字素簇，但只测试空字符串。我猜WordPress中的某些东西不是对性能敏感的要求被过分强调。

在那张纸条上二十二点二十四分主页可能是一个很好的改变，在主页上引入了很多复杂性，因为它将重新纳入对正常影响更大的事物的指标，但我认为，如果我们有一个拥有100篇帖子、1000条评论、大量媒体和大量定制的网站，情况会更好，甚至可能安装了一些常见的插件。

我们可以在每次运行时以原始状态执行数据库转储和恢复。

不过，我想知道是什么让我们不信任它？

简单地说：有时报告中值的 wp-total公司例如，可以是50ms，在下一次运行中可以是80ms。这使得建立信任和发现异常值有点困难。

尽可能多地消除基准中的外部偏见。

是的，这可能用得更好。这是我目前正在研究的部分内容。Cron、外部http请求等。

以故意忽略最坏的性能问题为代价，如果我们还没有开始的话，一种方法是在报告任何指标之前忽略数据中的异常值。如果我们在进行过程中更新度量，例如平均值，那么这是不可能发生的。

至少我们现在使用中值来忽略异常值，所以这是一个开始。

在计算合计度量之前，我们需要获得每个样本，以便确定给定的样本是否为异常值。再进一步，我们总是可以公开原始数据以供进一步审查。

这是一个长期目标；只是把所有的原始数字放进Grafana之类的东西里，然后在那里做进一步的分析。

空的测试站点是如此不切实际，以至于数字意义不大。

FWIW核心未使用空站点。我们使用https://github.com/WordPress/theme-test-data作为基础。不是一百篇帖子，但这是一个开始。但同意这与一个“典型的”小型WordPress网站还相去甚远。

我的草稿文档和一些初步测试结果可以在这里找到：https://docs.google.com/document/d/1elp9i9syVR6hCZEc_mRUl4E58JIbgBeO-Y6Xj85xiHE/edit

尽管我还不确定该如何看待这些结果，但我还是希望更多的人关注它。

虽然在GitHub Actions等不一致的环境中会出现这种情况

值得一提的是，我花了大量时间试图找出与GitHub Actions测试运行程序相关的可变性，最终我无法找到足够的证据表明这是一个真正的问题。

性能指标的这种高度差异可以在以下地方看到WordPress Code Vitals仪表板，它是从GitHub Actions在每次WordPress核心提交时提供的数据：

高方差在某些方面可以促进性能跟踪，因为它可以在较小的影响中过滤出误报。要将某些东西注册为真正的性能改进或回归，它必须具有可测量的超出噪音的影响。

也使用内置Docker环境

既然它给环境带来了一些人为的性能变化，我们真的想要这样吗？I/O尤其受此影响。似乎在Docker之外本地运行PHP、Apache和mysql会带来更真实的测量结果。

尽管Docker环境中的标准偏差有所下降，但测试运行时间也延长了16%左右。我想知道Docker中的某些I/O瓶颈实际上是导致标准偏差减少的原因。例如，运行更加不稳定的代码被掩盖并规范化，因为I/O等待时间在度量中变得更加重要。他们可能不是更好的因为变异性较低；可能是我们遮蔽可变性和隐藏我们关心的测量。

通过在请求之间应用某种类型的sleep（）或在其网络节流中应用某种请求延迟来屏蔽这些影响。

收集一系列延迟的结果可以非常暴露。我将尝试在Playground实例上进行一些测试，因为我们控制Playgrround中的整个环境，让我们可以做一些有趣的事情，比如在文件I/O和数据库I/O上添加任意延迟或突发效应。

感谢您的全面帖子，@瑞士风格。我突然想到的一件事是，测试运行的次数似乎与各种测试方法中标准偏差的减少无关。我想里面可能藏着别的东西。也许它更能表达双峰或多峰分布。我当然想更好地理解为什么事情看起来本质上如此多变，但我认为答案可能是WordPress运行时性能本质上是可变的。

我认为时间在我们这边。由于我们仍处于跨提交跟踪性能的初级阶段，所以我不明白为什么我们不能缓慢开始并运行需要更多时间并产生更多有用数据的实验。有了古腾堡，我常常希望我们不要对每个公关都进行性能测试，而是在大旅行箱在某个定期计划中：每天一次，每小时一次，尽可能快地进行测试等等……我仍然认为，由于我在笔记本电脑和专用服务器上看到的偏差，在多个样本和多个小时之间运行测试是有价值的。有些东西如果测试运行占用的墙时间少于几个小时，则很难从结果中提取出这种偏差。

按照时间表运行测试会失去性能变化与给定PR的直接关联，但我也发现，per-PR测试运行的承诺同样让我们失望。由于某种原因，古腾堡的性能回归通常落后于引入它们的公关，通常在其他工作与之相吻合时才会触发回归。至少，如果每天都运行测试，那么可能会引入一小部分公关，因此，这意味着开始平分并找出问题所在并不难。

GitHub上的WordPress组织拥有GitHubAction跑步者的企业配额；我们不需要担心会用完那里的配额。

随着时间的推移，有一些更具变数的常规测试可能会有价值（正如我认为的那样@你知道riad我们试图沟通，历史追踪器对古腾堡有多大价值），然后当我们认为我们有回归或改进时，转移到一个单独的统计过程中。即使在高度可变的环境中，统计方法也可以帮助揭示真实的影响，但它们需要花费大量时间，并且最适合于这些单独的问题：这一变化是否影响性能以及如何影响性能？

换言之，也许我们从获取一些指标开始，并不太担心可变性，因为这种可变性不会掩盖长期趋势，甚至可以帮助我们避免误诊可能存在或不存在的微小性能影响。我们可以随着时间的推移进行改进，甚至可以以递增的方式在我们的实验上运行实验。我在古腾堡（Gutenberg）的性能测试中进行了许多实验，以解决不同的可变性和偏见问题，大多数实验结果都缺乏证据表明，他们改进了一些东西，甚至起初认为这些东西似乎有帮助。

我们真的想要这样吗，因为它给环境带来了一些人为的性能变化？I/O尤其受此影响。似乎在Docker之外本地运行PHP、Apache和mysql会带来更真实的测量结果。

Docker在托管空间中并不少见，而且它使在本地运行测试更加容易。所以这有利弊。

GitHub上的WordPress组织拥有GitHubAction跑步者的企业配额；我们不应该担心那里的配额会用完。

很高兴知道！然后，我们还可以尝试使用更大、更核心的跑步者。

换言之，也许我们可以从获取一些指标开始，而不用太担心可变性

我倾向于同意，也同意每天多次测试的观点。如果我们可以将原始数据发送到仪表板并在那里进行统计分析，那肯定是有价值的。我一直在研究格拉法纳这样的事情的原因之一。

在过去几周里，我花了大量时间深入研究我们开发的基准自动化https://github.com/swissspidy/compare-wp-performance网站用于比较不同WP版本。这种自动化利用了两个主要的基准测试CLI脚本对于我们一直作为性能团队使用的服务器计时和web重要信息。

我想回答的一个问题是，是否有一种统计方法来表示一组运行期间预期的方差量，而不是试图完全消除方差。通过这种方式，我们可以判断衡量的变化在统计上是否显著，或者是否在我们的基准测试方法中固有的预期方差范围内。

虽然到目前为止我还没有回答这个问题，但我注意到，即使在相同的环境中，两组运行之间的差异也会对两个版本的基准比较产生很大影响。我关于报告基准的工作原理是，如果我们对比较工作流进行多次运行（每个版本都需要100个样本），并对运行的中值（p50）进行平均，那么我们至少可以报告一个有用的度量值。为了有效地做到这一点，我修改了GH工作流，使其并行运行5次，并将结果发布到GH操作的摘要中。通过在单独的GH工作人员中进行多次测试，而不是在单个跑步者中进行大量的样本测试，我们至少可以考虑工作人员在结果中引入的偏见（理论上）。以下是比较WP 6.3.2和6.4-RC4的最新示例.

这些报告包括我们最近添加到基准脚本中的一些新的可变性数字，因此我们可以看到每组基准样本的标准偏差（SD）、平均绝对偏差（MAD）和四分位范围（IQR）。一般来说，我预计在同一个GH工作者身上采用的两组基准会导致类似的分布，但情况似乎并非如此，这进一步扭曲了直接比较的有用性。例如，如果您查看LCP（p50）数字运行1在这组基准测试中，它表明LCP52.52%更差在WP 6.2.3和WP 6.3.2之间，我们知道情况并非如此。然而，您也可以看到，两次运行的MAD和IQR计算的离散度相差超过800%，因此这些看起来根本不是有用的比较，因为分布的形状非常不同。当两个基准之间的离散度相似时，我们至少看到一些预期的和可重复的结果，但我很好奇如何解释分布如此不同的比较。

@乔麦吉尔我最近还遇到了一个基准测试，所有指标突然下降了50%。正如你所说，情况显然不是这样。虽然从统计上看，这可能不合适，但如果我们要使用5个中值的“平均值”，我建议我们放弃这样的运行，再进行一次。或者，我们坚持使用5个中间值的中间值，以避免此类问题。我认为从统计数据来看，后者更合适。

我也没有强烈的感觉，但我做认为我们需要确保极端明显错误的离群值运行不会对总体结果产生太大影响。

但我确实认为，我们需要确保这种明显错误的极端异常运行不会对总体结果产生太大影响

当然，我完全同意。当我第一次遇到这个问题时，我认为它可能是一个边缘情况——只是一些随机的异常，因为GH工作人员行为古怪——但我看到这种情况在多运行基准测试结果中经常出现，这似乎很重要，因为即使在我们的WP Core和Gutenberg工作流中，也可能受到相同类型的分散异常的影响。

需要记住的一点是，我们正在使用非常相似的过程来实现稍微不同的目的，所以策略可能有点不同。基本上，我们使用基准测试：

1. 在开发过程中定期进行基准测试，以确定绩效的变化（积极或消极）。
2. 比较WP的两个版本，以共享版本之间的质量差异。

对于前者，我们可以接受更高水平的方差，因为我们真正感兴趣的是跨时间的趋势，而不仅仅是一个快照。对于该用例，我认为文章链接 @瑞士风格在他的探索文档中，关于使用阶跃滤波是一个值得进一步探索的有趣想法。

对于后者，我们确实需要改进方法，使定性比较易于理解，同时不掩盖所有必然影响实际测量的环境因素。我认为，理解为什么这些运行会在同一个系统上显示出如此出乎意料的分散差异，将有助于我们在这里。

比较WP的两个版本，以共享版本之间的质量差异。

如果在同一作业中对两个WP版本进行比较。（相同的CI作业运行两个版本），信任数字IMO是完全可以的（假设这些数字在图中证明了一定的稳定性）。

的确，不同工作之间的数字不可信，这就是为什么我们在图表中“正常化”的原因。我猜Github的跑步者使用虚拟化，这会受到同一硬件上虚拟实例数量的严重影响。我不确定我们在这里能做什么。

编辑：当我说信任数字时，我的意思是信任两个版本之间的相对差异，数字的绝对值非常依赖于runner实例，不能用作参考值。

如果在同一作业中对两个WP版本进行比较。（相同的CI作业运行两个版本），完全可以信任IMO的数字（假设这些数字在图中具有一定的稳定性）。

这也是我的假设，但令人惊讶的是，在许多情况下，即使在同一个CI工作中，从两个版本收集的数据也不可比较，因为它们在方差上表现出非常不同的特征。为了将其可视化，请考虑将两组样本表示为方框图。一般来说，在同一个作业中，我希望测试的两个版本的方框图具有相似的形状，因此我们可以测量方框在测试a和测试B之间移动了多少。然而，我看到许多实例中，两个方框完全不同，即使在同一CI运行中，这让我怀疑最初的假设，除非可以解释（并希望消除）。

我看到许多情况下，即使在同一个CI运行中，两个框也是完全不同的，这让我怀疑最初的假设，除非可以解释（并希望消除）。

我们在古腾堡性能测试中也有过这样的案例，最近一次，正如你在“第一块（站点编辑器）”指标上看到的那样https://www.codevitals.run/project/gutenberg网站

一般来说，这是因为我们的测试/度量不够确定，可能会受到“计时”/“自动保存触发器”等因素的影响。。。或任何随机的事情。这通常与环境无关，需要逐个度量单独确定。例如，这就是我们如何为上述指标修复它的方法WordPress/gutenberg#55922

一般来说，这是因为我们的测试/度量不够确定

我觉得这有点道理。即使在CWV度量存在巨大差异的运行中，服务器响应时间度量也相当稳定。我们可能需要进一步研究如何具体稳定CWV。

我们可能需要进一步研究如何具体稳定CWV。

如果你看看我上面分享的文档，我在Lighthouse的网络节流方面得到了一些有希望的结果

是的，只是看着那个！解决方案F中的快速3G结果是我见过的最好的结果。我很好奇你是如何实现节流的，我们是否可以在不改变下载速度的情况下引入网络延迟，并且在总体时间上牺牲更少的情况下仍然看到类似的结果？下面是引擎盖下的节流选项用于比较Puppeter的“快速3G”设置。

下面是我的一些一次性代码：https://github.com/swissspidy/wordpress-develop/pull/42/files#diff-3ffa7f38ac5fb9027780e74315b92dcbc18eec9042c34cfcfa7d9f3185d89b8f

+1，因为我对节流进行了更多的研究（我最后刚刚完成了对文档的审查）。

我们也可以尝试更新https://github.com/swissspidy/compare-wp-performance网站作为测试，考虑到这一点应该很容易基准-关键点已经支持节流（道具@威斯顿鲁特).

为了露齿一笑，我推动了比较WP性能工作流的一个分支，该工作流使用节流功能对网络重要信息进行基准测试，并将样本数量减少到20个，这样我就可以快速了解该更改的影响。这是结果虽然没有任何主要的异常值，但分散性似乎没有中的示例好@瑞士风格的医生，所以不确定这是答案。

不管该文档中探索的所有想法如何，该文档中的媒介在不同的运行之间已经比我们在GitHub工作流中看到的更接近了。这让我觉得最重要的改变可能是使用专用的云环境，比如@瑞士风格对文档中的所有数字都做了吗？

我希望测试的两个版本的方框图具有类似的形状

@乔麦吉尔我们可能想对此表示怀疑。任何代码更改都可能会对方差产生影响。事实上，我们添加的缓存越多，我们应该期望的差异就越大，因为这为给定的代码路径引入了至少两种性能模式：一种是预处理的，另一种是未预处理的。另一个例子是，如果我们添加一些运行每个X请求的东西来执行一些清理或维护，类似于WP CRON作业。代码的每一条发散路径都代表不同的性能特征，这将分散样本中的预期变化。

如果我们从同一人群中测量两组人，假设方差相等是很好的，但在我们改变代码的情况下，我们实际上是在改变人群，这个假设不成立。测试跑步者也是如此；由于SSD和旋转磁盘的结构不同，它们的响应时间可能会有不同的差异，测试运行程序上的系统负载也是如此。

单独分析方差有很大的价值。通常，主要的性能改进实际上可能会增加中值响应时间，但会减少变化，或者更重要的是，长尾偏差在最坏的情况下好多了通常比一般情况下稍微好一点.

这通常与环境无关，需要逐个度量单独确定

想要回应什么@你知道riad用这个在这里说。我认为每个测试环境都有一些固有的偏见（我只能通过测试来缓解这些偏见跨越多个小时的实时时钟时间)以及我们测试的代码固有的偏见。也就是说，我们没有考虑WordPress内部的某些东西，这些东西会在非常可控的设置下导致给定页面的呈现时间出现差异。

我们正在使用非常相似的过程来实现略有不同的目的，因此策略可能会有所不同

👍 完全同意。看到这一趋势相对容易。确定一个特定的更改是否产生了真正的影响以及它是什么样的影响要困难得多，我们几乎总是会出错，但我们可以提供对更改的深入了解。

无论测试环境多么糟糕，显而易见的胜利总是会显现出来，但小的或微的优化总是会采取一些极端的措施来验证，而这些验证往往会产生误导，因为我们在测试中没有提出正确的问题。他们很可能在我们不注意的地方损害性能，而在我们所在的地方提高性能。

在一系列延迟的情况下收集结果可能会很有启发性。我将尝试在Playground实例上进行一些测试，因为我们控制Playgrround中的整个环境，让我们可以做一些有趣的事情，比如在文件I/O和数据库I/O上添加任意延迟或突发效应。

@dmsnell公司你最终会那样做吗？这是我们还没有探索的东西，所以我很好奇这是否可行。

不幸的是@瑞士风格我还没有。我一直在开始，但被拉到了其他工作中。

有一个添加文件系统日志的示例，可以遵循该示例来引入延迟：

https://github.com/WordPress/WordPress操场/blob/71419eb36bad02884809b7c751a6457d715da9aa/packages/php-wasm/fs期刊/src/lib/fs期刊.ts#L151-第159页

我的意图是从一些基本的东西开始，比如基于合理SSD和合理服务器HDD的高斯随机分布。也就是说，对于HDD模拟，功能截取I/O会根据类似µ=9ms的值为请求添加给定的延迟。随着时间的推移，如果结果能够证明这一点，那么这将是扩展真实磁盘I/O和缓存效果建模的绝佳机会。

当然还有另一个用于网络延迟的函数或接口，尽管我认为I/O更重要。