发布于 由admin

PHP中的性能回归测试：在CI/CD中利用基准测试（Benchmarking）定位延迟增加的提交

PHP 性能回归测试：在 CI/CD 中利用基准测试定位延迟增加的提交

大家好！今天我们要深入探讨一个关键的软件开发实践领域：PHP 性能回归测试，以及如何在 CI/CD 流程中有效地利用基准测试来定位引入延迟增加的提交。

性能回归的挑战

软件开发是一个持续演进的过程。每一次代码变更，无论是修复 bug、添加新功能还是进行重构，都可能对应用程序的性能产生影响。 性能回归是指在代码更新后，应用程序的性能相比之前版本下降的现象。这种下降可能是微小的，也可能是显著的，但无论如何，都需要及时发现和解决。

性能回归带来的危害是多方面的：

  • 用户体验下降： 响应时间变慢会导致用户体验下降，用户可能会感到沮丧和不满。
  • 资源消耗增加： 性能下降通常意味着需要更多的服务器资源来处理相同的负载，从而增加运营成本。
  • 业务损失： 在某些情况下，性能问题甚至可能导致业务损失，例如电商网站的转化率下降。

因此，建立一套完善的性能回归测试体系至关重要。

基准测试：性能评估的基石

基准测试（Benchmarking）是评估应用程序或代码片段性能的一种标准方法。它涉及运行一系列预定义的测试用例，并测量关键性能指标，例如执行时间、内存使用量、CPU 占用率等。通过比较不同版本代码的基准测试结果，我们可以确定是否存在性能回归。

在PHP中，我们可以使用多种工具和技术进行基准测试：

  • Xdebug： 这是一个强大的调试和分析工具，可以用来 profiling PHP 代码，找出性能瓶颈。
  • Blackfire.io： 这是一个专业的性能分析平台，提供可视化的性能报告和建议。
  • PHPBench： 这是一个专门为 PHP 设计的基准测试框架，可以方便地编写和运行基准测试用例。

我们将主要使用 PHPBench，因为它专门为 PHP 基准测试设计，并且易于集成到 CI/CD 流程中。

PHPBench 简介

PHPBench 是一个开源的 PHP 基准测试框架，它允许你编写简单的 PHP 类来定义你的基准测试。

以下是一个简单的 PHPBench 基准测试示例：

<?php

namespace Acme;

use PhpBenchAttributesIterations;
use PhpBenchAttributesRevs;

class StringBench
{
    #[Revs(1000)]
    #[Iterations(5)]
    public function benchStrlen(): void
    {
        strlen('foobar');
    }
}
  • Revs: 指定基准测试循环执行的次数。
  • Iterations: 指定基准测试运行的迭代次数。

运行这个基准测试，PHPBench 会多次执行 strlen('foobar')，并计算平均执行时间。

在 CI/CD 中集成基准测试

为了在 CI/CD 流程中集成基准测试，我们需要执行以下步骤：

  1. 编写基准测试用例： 针对关键功能和代码路径编写基准测试用例。
  2. 配置 CI/CD 管道： 在 CI/CD 管道中添加一个步骤，用于运行基准测试。
  3. 收集和分析基准测试结果： 将基准测试结果与历史数据进行比较，以检测性能回归。
  4. 设置性能回归阈值： 定义性能回归的阈值，当性能下降超过阈值时，CI/CD 管道应该失败。

以下是一个使用 GitHub Actions 的 CI/CD 管道示例：

name: PHP Benchmarks

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  benchmarks:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: xdebug

      - name: Install dependencies
        run: composer install --no-interaction --prefer-dist --optimize-autoloader

      - name: Run benchmarks
        run: ./vendor/bin/phpbench run --report=aggregate

      - name: Store benchmark results
        uses: actions/upload-artifact@v3
        with:
          name: benchmark-results
          path: phpbench_aggregate.json

这个 CI/CD 管道会在每次 push 或 pull request 到 main 分支时运行基准测试。它首先设置 PHP 环境，安装依赖项，然后运行 PHPBench。最后，它将基准测试结果存储为一个 artifact。

检测性能回归

仅仅运行基准测试是不够的，我们需要能够检测性能回归。这可以通过以下方式实现：

  1. 存储历史基准测试结果： 将每次 CI/CD 运行的基准测试结果存储在一个数据库或文件中。
  2. 比较当前结果与历史结果： 将当前基准测试结果与历史结果进行比较，计算性能变化百分比。
  3. 设置性能回归阈值： 定义性能回归的阈值，当性能下降超过阈值时，发出警告或使 CI/CD 管道失败。

以下是一个示例 PHP 脚本，用于比较当前基准测试结果与历史结果：

<?php

// Load current benchmark results from JSON file
$currentResults = json_decode(file_get_contents('phpbench_aggregate.json'), true);

// Load historical benchmark results from database or file
$historicalResults = json_decode(file_get_contents('historical_benchmarks.json'), true);

$threshold = 0.05; // 5% threshold

$regressions = [];

foreach ($currentResults['reports'] as $report) {
    foreach ($report['subjects'] as $subject) {
        $subjectName = $subject['name'];

        // Find corresponding historical result
        $historicalSubject = null;
        foreach ($historicalResults['reports'] as $historicalReport) {
            foreach ($historicalReport['subjects'] as $hs) {
                if ($hs['name'] === $subjectName) {
                    $historicalSubject = $hs;
                    break;
                }
            }
        }

        if ($historicalSubject === null) {
            echo "No historical data found for subject: $subjectNamen";
            continue;
        }

        // Calculate performance change
        $currentAvgTime = $subject['stats']['mean'];
        $historicalAvgTime = $historicalSubject['stats']['mean'];

        if ($historicalAvgTime == 0) {
            echo "Historical Avg Time is zero for subject: $subjectNamen";
            continue;
        }

        $percentageChange = ($currentAvgTime - $historicalAvgTime) / $historicalAvgTime;

        // Check for regression
        if ($percentageChange > $threshold) {
            $regressions[] = [
                'subject' => $subjectName,
                'percentage_change' => $percentageChange,
                'current_avg_time' => $currentAvgTime,
                'historical_avg_time' => $historicalAvgTime,
            ];
        }
    }
}

// Output regressions
if (!empty($regressions)) {
    echo "Performance regressions detected:n";
    foreach ($regressions as $regression) {
        echo sprintf(
            "  Subject: %s, Percentage Change: %.2f%% (Current: %.6f, Historical: %.6f)n",
            $regression['subject'],
            $regression['percentage_change'] * 100,
            $regression['current_avg_time'],
            $regression['historical_avg_time']
        );
    }
    exit(1); // Fail the CI/CD pipeline
} else {
    echo "No performance regressions detected.n";
    exit(0); // Pass the CI/CD pipeline
}

这个脚本首先加载当前的基准测试结果和历史结果。然后，它遍历每个基准测试用例，计算性能变化百分比。如果性能下降超过阈值，它会将该用例添加到 regressions 数组中。最后，它输出所有的性能回归，并根据是否存在回归来决定是否使 CI/CD 管道失败。

将历史数据存储在何处？

根据你的项目需求和基础设施，你可以选择不同的存储方案：

  • 数据库： 可以使用 MySQL、PostgreSQL 等关系型数据库，或者 MongoDB 等 NoSQL 数据库。
  • 文件系统： 可以将历史结果存储在 JSON 文件或 CSV 文件中。
  • 云存储： 可以使用 Amazon S3、Google Cloud Storage 等云存储服务。

如何选择性能回归阈值？

性能回归阈值的选择取决于你的项目需求和风险承受能力。一般来说，建议选择一个较小的阈值（例如 5%），以便及时发现性能问题。但是，过小的阈值可能会导致误报，因此需要根据实际情况进行调整。

定位延迟增加的提交

一旦检测到性能回归，下一步就是定位引入延迟增加的提交。这可以通过以下方式实现：

  1. 使用 git bisect： 这是一个强大的 Git 工具，可以用来二分查找引入 bug 或性能问题的提交。
  2. 分析代码变更： 仔细检查引入延迟增加的提交中的代码变更，找出可能导致性能问题的代码。
  3. 使用性能分析工具： 使用 Xdebug 或 Blackfire.io 等性能分析工具，找出性能瓶颈。

使用 git bisect

git bisect 可以帮助你快速定位引入性能回归的提交。它的工作原理是二分查找：

  1. 首先，你需要指定一个已知的良好提交（即没有性能问题的提交）和一个已知的错误提交（即存在性能问题的提交）。
  2. 然后，git bisect 会自动 checkout 中间的提交，你需要运行基准测试，并告诉 git bisect 该提交是好的还是坏的。
  3. git bisect 会重复这个过程，直到找到引入性能问题的提交。

以下是使用 git bisect 的示例：

git bisect start
git bisect good <good_commit>
git bisect bad <bad_commit>

# git bisect 会自动 checkout 中间的提交
# 运行基准测试，并告诉 git bisect 该提交是好的还是坏的
./run_benchmarks.sh

if [ $? -eq 0 ]; then
  git bisect good # 基准测试通过
else
  git bisect bad # 基准测试失败
fi

# git bisect 会重复这个过程，直到找到引入性能问题的提交
git bisect reset

分析代码变更

找到可疑的提交之后，仔细检查该提交中的代码变更。重点关注以下几个方面：

  • 算法复杂度： 是否有代码变更引入了更差的算法复杂度？例如，从 O(n) 变为 O(n^2)。
  • 数据库查询： 是否有代码变更导致了更多的数据库查询？或者导致了查询效率降低？
  • 循环： 是否有代码变更导致了循环次数增加？或者循环体内的操作更加耗时？
  • 外部依赖： 是否有代码变更引入了新的外部依赖？或者升级了现有依赖的版本？

使用性能分析工具

使用 Xdebug 或 Blackfire.io 等性能分析工具，可以帮助你找出代码中的性能瓶颈。这些工具可以告诉你哪些函数调用占用了最多的时间，以及哪些代码行导致了最多的内存分配。

通过结合以上方法，你应该能够快速定位引入延迟增加的提交，并找到导致性能问题的根本原因。

代码示例：更复杂的基准测试

假设我们有一个函数，用于对一个数组进行排序，我们想要测试不同排序算法的性能：

<?php

namespace Acme;

use PhpBenchAttributesIterations;
use PhpBenchAttributesRevs;

class SortBench
{
    private array $array;

    public function __construct()
    {
        $this->array = range(1, 1000);
        shuffle($this->array);
    }

    #[Revs(100)]
    #[Iterations(5)]
    public function benchSort(): void
    {
        sort($this->array);
    }

    #[Revs(100)]
    #[Iterations(5)]
    public function benchUsort(): void
    {
        usort($this->array, function ($a, $b) {
            return $a <=> $b;
        });
    }
}

这个基准测试类定义了两个基准测试方法：benchSort 和 benchUsort。benchSort 使用 PHP 内置的 sort 函数进行排序，benchUsort 使用 usort 函数进行排序。构造函数用于初始化一个包含 1000 个元素的数组，并对其进行洗牌，以确保每次运行基准测试时，数组都是随机的。

表格：基准测试结果示例

假设我们运行了上述基准测试，并得到了以下结果：

基准测试方法 平均执行时间 (秒) 内存使用量 (MB)
benchSort 0.0001 0.1
benchUsort 0.0002 0.15

从这个表格中可以看出，benchSort 的平均执行时间比 benchUsort 快，内存使用量也更少。这表明 sort 函数的性能比 usort 函数更好。

CI/CD集成最佳实践

为了确保基准测试在CI/CD流程中发挥最大作用，请考虑以下最佳实践：

  • 并行运行基准测试： 如果你的项目包含大量的基准测试用例，可以考虑并行运行这些用例，以缩短 CI/CD 管道的运行时间。
  • 使用缓存： 缓存依赖项和构建产物，以减少 CI/CD 管道的运行时间。
  • 定期更新基准测试用例： 随着代码的演进，定期更新基准测试用例，以确保它们能够准确地反映应用程序的性能。
  • 监控基准测试结果： 持续监控基准测试结果，并及时处理性能回归。
  • 自动化分析： 尽可能自动化基准测试结果的分析过程，减少人工干预。

总结：保障PHP应用性能的关键

通过在 CI/CD 流程中集成基准测试，并设置性能回归阈值，我们可以及时发现和解决性能问题，确保应用程序的性能不会随着代码的演进而下降。利用git bisect和性能分析工具可以高效的定位问题提交和根本原因，从而保障PHP应用的性能。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注