使用 CBT 进行性能基准测试：运行和分析性能测试。第三部分
CBT 性能基准测试 - 第三部分。我们如何运行和分析性能测试？
博客系列大纲 ¶
目录
介绍 ¶
现在我们已经创建了擦除编码 (EC) 集群（来自 第一部分）并定义了 YAML 文件和工作负载（来自 第二部分），现在我们可以启动 CBT 性能基准测试了。
本部分将涵盖
- 运行性能测试
- 生成性能报告
- 如何读取响应时间曲线
- 比较性能基准测试
- 在 OSD 宕机的情况下运行性能测试
步骤 1：运行性能测试
首先，将 CBT GitHub 仓库 克隆到您选择的目录中，并 cd 进入该目录。
这是一个运行 CBT 性能测试的示例命令
python /cbt/cbt.py -a /tmp/cbt -c /example/ceph.conf /example/<yaml_file> 2>&1 | tee /tmp/cbt.out
您将指定 cbt 文件的位置（cbt.py）。提供一个归档文件夹，您的结果将在其中生成（/tmp/cbt）。提供一个配置文件文件夹（/example/ceph.conf），以便 CBT 可以连接到集群。最后，我们指定我们的 (yaml_file)，它将概述将要运行的测试/工作负载。
步骤 2：生成性能报告
一旦您按照 Pat 1 的说明运行了性能测试，您的结果文件将输出到您在 步骤 1 的归档参数 (-a) 中指定的地点。对我来说，之前的命令引用了 /tmp/cbt，所以我的结果就在那里。
- 现在，您可以将这些结果文件复制到新目录中，如果您愿意。我希望它们位于
/perftests/my_test中，因为我喜欢保留一个包含所有 CBT 测试结果的目录，并且我会在每次性能测试之前删除/tmp/cbt，因此这不是一个合适的存储位置。所以我会这样做，例如
cp -r /tmp/cbt/* /perftests/my_test
- 接下来，生成性能报告，对于我来说，可以使用以下命令：
PYTHONPATH=/cbt/ /cbt/tools/generate_performance_report.py --archive /perftests/my_test --output_directory /perftests/my_test_results --create_pdf
在上面，您再次引用了 cbt.py 的位置，然后引用了将生成性能报告的脚本（generate_performance_report.py）。我指定了包含性能运行结果的目录 /perftests/my_test，还应指定所需的 output_directory，这是性能报告文件的存储位置。
注意： 您不需要提前创建上述命令中看到的指定 output_directory，如果需要，它将自动为您创建。完成这些步骤后，您应该在新的 output_directory 中找到结果文件，在我的例子中，是 my_test_results 文件夹。您已成功生成 性能报告！我通常会将这些结果文件上传到 GitHub，以创建一个主存储库来存储和查看报告。
下一节将介绍生成的性能报告，以及如何理解您自己的报告。
如何读取响应时间曲线 ¶
现在您已经生成了测试的性能报告，您可能会查看 pdf 或 md 文件，并对显示的图表感到困惑。本节将介绍如何读取响应时间曲线并根据数据点得出结论。
让我们回到我们的示例 CBT 测试运行和我们开始的问题：“使用 CLAY 擦除编码插件是否比使用默认的 Jerasure 插件提供更好的性能？”
我生成了 Jerasure 插件 EC 池的性能报告，结果可以在 这里 找到。
然后我为 CLAY 插件做了同样的事情，这里。
在上述生成的报告中，您将看到绘制的曲棍球棒曲线，以显示每种配置的性能。
那么我们如何读取生成的曲线？ ¶
这是一个性能报告中生成的曲线示例：
下面是 total_iodepth 值的示例。如上所述，我们可以通过检查我们之前在此测试中使用的 yaml 文件来找到每个指定的 total iodepth 点，它也位于性能报告的“Configuration yaml”部分中。对于上面的示例，它是
total_iodepth: [ 2, 4, 8, 12, 16, 24, 32, 64, 96, 128, 192, 288, 384 ]
垂直红色线条（误差线）显示特定曲线点的性能的标准偏差/方差量。如果标准偏差很小，则表明该工作负载的性能稳定。随着响应曲线开始向上弯曲，性能变得更加可变，标准偏差增加。
- 对于 FIO 工作负载，CBT 将启动每个卷的一个 FIO 实例。
- 值得注意的是，报告生成的图表不包括“预热”期间的结果。
后处理工具将汇总 IOPS 以生成响应曲线的总 IOPS，并计算所有卷上的平均延迟。IOPS 与延迟然后绘制在曲线上的该点的曲线中。
从响应曲线中读取哪些值？ ¶
- 如果您知道应用程序生成了多少 I/O，那么您可以使用响应曲线来了解应该期望的延迟
- 如果您想查看存储控制器可以处理的最大 I/O 量，请找到曲线上的最右侧点，并找到 X 轴上的值。
- 如果您有延迟要求，例如所有 I/O 必须在 2 毫秒内完成，那么您可以找到曲线上的该延迟点，以找到存储控制器可以执行的最大 I/O 量。
- 大多数时候，您不知道应用程序将生成多少 I/O，并且希望确保即使 I/O 量出现峰值或突发，也不会导致延迟发生重大变化。在响应曲线平坦的地方，即使 I/O 量发生变化，延迟也不会有太大变化，而在响应曲线向上弯曲的地方，I/O 量的微小变化可能会对延迟产生重大影响。在响应曲线开始快速增加之前选择一个点，可以很好地指示您可以在保持稳定性能的情况下可以执行的最大 I/O 量。
- 大多数用户不希望在超过最大吞吐量的 70% 的情况下运行，因为这为扩展提供了一些空间，并允许在工作负载中出现突然的爆发，以便可以容忍高延迟。
如 第一部分 中所述，理想的响应曲线将是一条平坦的水平线，显示随着 I/O 量增加，延迟保持恒定，直到我们达到饱和点，系统无法处理更多 I/O。这是因为它突出了性能的一致性和更少的方差。
步骤 3：生成比较报告
使用 CBT，除了性能报告外，我们还可以快速生成 比较报告。现在我已经运行了 CLAY 和 Jerasure 的测试，我们可以生成一个性能报告来比较它们。我将使用以下命令来执行此操作
PYTHONPATH=/cbt/ /cbt/tools/generate_comparison_performance_report.py --baseline /perftests/jerasure_test/ --archives /perftests/clay_test/ --output_directory /perftests/clay_vs_jerasure_comparison --create_pdf
在上面的命令中，我们需要指定基准是什么，我们将使用上面的 Jerasure 测试文件夹作为 基准曲线。我们的 归档曲线 将是我们的 CLAY 性能报告测试文件夹。重要的是，在上面的命令中，您输入的是 Jerasure 和 CLAY 的 测试 文件夹，而不是 前面步骤中生成的 结果 文件夹。上面的命令将在我们指定的 output_directory 中生成一个比较报告。
您已成功生成 比较报告！我的报告可以在 这里 找到。
比较报告的基本分析： ¶
让我们先了解一下我们的两个擦除编码配置文件：Jerasure 是一个通用的 Reed-Solomon 擦除编码库，它是基于矩阵的，未针对 CPU 进行优化。它在读写之间相对平衡。CLAY 旨在以牺牲更复杂的写入路径为代价来提高恢复速度。因此，我们预计 CLAY 在 较小 的 IO 大小时可能表现更好，但随着写入变得 更大，我们可能会看到 CLAY 性能下降，从而导致更好的 Jerasure 结果。此外，在读取方面，我们预计由于它们的实现非常相似，因此性能大致相同，主要区别在于写入。
现在让我们看一下比较报告，首先比较较小的负载，从 4K 随机读取 开始，这是相应的图表：
如上图所示，橙色曲线是我们的 CLAY EC 池，蓝色曲线是我们的 Jerasure EC 池。我们可以看到，对于 4k 随机读取，性能几乎没有变化，正如我们预期的那样。两条曲线的延迟和 IOps 几乎相同。
我们还可以查看 4K 随机写入：
性能相似，直到我们达到饱和点，约为 14,000 IOps，此时我们可以看到 Jerasure 和 CLAY 的延迟急剧上升。此时，Jerasure 的 IOps 略好于 CLAY，但没有实质性差异。
总的来说，我们可以看到在小负载下，Jerasure 和 CLAY 之间的性能非常相似。
现在让我们转向更大的负载，从 1024K 顺序读取 开始：
再次，两条曲线几乎没有差异，并且遵循非常相似的路径，这是预期的。这是因为对于正常的读取，ceph 只需要获取数据块（而不是奇偶校验块）。Jerasure 和 CLAY 实际上只是返回存储的对象，除非发生故障，否则没有真正的差异。
现在让我们看看 1024K 顺序写入：
现在当我们查看写入时，我们看到 CLAY 的延迟高 20-60%，吞吐量下降，与 Jerasure 相比。这可能是由于 CLAY 中额外的 CPU 和网络需求造成的。更大的写入意味着更大的编码矩阵/层，并且 CLAY 比 Jerasure 具有更复杂的写入，这可能导致显示的更高延迟。
我们的顺序写入基准测试表明，Jerasure 在所有块大小上都能提供更一致的写入性能，而 CLAY 更加不稳定，在一些较小的尺寸上表现更好，但在大型顺序写入方面表现更差。这表明 CLAY 的设计重点：它针对减少恢复带宽而不是原始写入性能进行了优化。
这意味着，如果您的 I/O 工作负载主要是大型顺序读取，例如用于 AI 训练的 数据湖，那么切换到 CLAY 不会影响性能。但是，如果您的 I/O 工作负载主要是繁重的顺序写入，例如 存储档案或备份，那么切换到 CLAY 将产生实质性的负面性能影响，如图所示。
步骤 4：在 OSD 宕机的情况下运行测试
因此，在之前，我们比较了 CLAY 和 Jerasure EC 池。结果证实了我们的假设，即 Jerasure 可能表现更好，因为用于恢复数据计算更复杂。现在我们将进行另一次运行，并故意在运行 CBT 测试之前关闭一个 OSD，以模拟可能发生的真实世界故障，看看两者在 OSD 恢复方面的性能有何不同。
以下比较报告显示了 CLAY 和 Jerasure 曲线，其中两个插件都关闭了一个 OSD。该报告可以在 这里 找到。
现在，我们将查看上述比较报告中的 1024K 顺序读取：
现在我们预计 CLAY 的性能会更好，因为它据称具有更高效的数据恢复。但是，如图所示，事实并非如此。
总结 ¶
在这部分中，我们使用了 CBT 来成功比较 Jerasure 和 CLAY 在各种不同工作负载下的性能。我们生成了可重复的结果，表明对于良好的路径 I/O 以及 OSD 宕机时的 I/O（因此需要使用纠删编码来重建数据），使用 CLAY 没有优势。事实上，存在额外的开销，这意味着使用 CLAY 时的性能可能会更差。
结论 ¶
总而言之，这篇博文展示了如何从头到尾生成 CBT 性能基准测试运行的无缝体验，在生成性能报告的同时，并能够分析/比较性能。我们使用 CLAY 和 Jerasure 作为演示如何轻松进行性能基准测试的示例，但有时结果可能出乎意料，导致提出的问题多于获得的答案。这可能导致进一步的实验，深入研究为什么会发生某些结果，而我将在博文的 Part 4 中进行此操作，该部分将在不久的将来发布。Part 4 将提供更详细的分析和 IO 分解，以阐明为什么 CLAY 的性能更差！