Help us learn about your current experience with the documentation. Take the survey.

负载性能测试

  • 版本:Premium, Ultimate
  • 产品:GitLab.com, GitLab Self-Managed, GitLab Dedicated

通过负载性能测试,您可以在 GitLab CI/CD 中测试待处理的代码更改对应用程序后端的影响。

GitLab 使用 k6(一个免费的开源工具)来测量应用程序在负载下的系统性能。

与用于测量网站在客户端浏览器中性能的浏览器性能测试不同,负载性能测试可用于对应用程序端点(如 API、Web 控制器等)执行各种类型的负载测试。 这可用于测试后端或服务器在大规模下的性能表现。

例如,您可以使用负载性能测试对应用程序中一个热门的 API 端点执行大量并发的 GET 请求,以查看其性能表现。

负载性能测试的工作原理

首先,在您的 .gitlab-ci.yml 文件中定义一个用于生成负载性能报告产物的作业。 GitLab 会检查此报告,比较源分支和目标分支之间的关键负载性能指标,然后在合并请求组件中显示这些信息:

Load Performance Widget

接下来,您需要配置测试环境并编写 k6 测试脚本。

测试完成后,合并请求组件会显示以下关键性能指标:

  • Checks(检查):k6 测试中配置的检查项通过率百分比。
  • TTFB P90:开始接收响应所需时间的第 90 百分位数,即首字节时间 (TTFB) 的 P90 值。
  • TTFB P95:TTFB 的第 95 百分位数。
  • RPS:测试能够达到的平均每秒请求数 (RPS)。

如果负载性能报告没有可供比较的数据(例如,当您首次在 .gitlab-ci.yml 中添加负载性能作业时),负载性能报告组件将不会显示。在针对该目标分支的合并请求中显示之前,它必须在目标分支(例如 main)上至少运行过一次。

配置负载性能测试作业

配置负载性能测试作业可以分为几个不同的部分:

  • 确定测试参数,例如吞吐量等。
  • 为负载性能测试设置目标测试环境。
  • 设计并编写 k6 测试脚本。

确定测试参数

您需要做的第一件事是确定您想要运行的负载测试类型以及您希望如何运行它(例如,用户数量、吞吐量等)。

请参阅 k6 文档,特别是 k6 测试指南以获取指导。

测试环境设置

负载性能测试工作的很大一部分是准备目标测试环境以应对高负载。您应确保它能够处理测试时所用的吞吐量

通常,还需要在目标环境中准备具有代表性的测试数据,以供负载性能测试使用。

我们强烈建议不要在生产环境中运行这些测试

编写负载性能测试

环境准备就绪后,您就可以编写 k6 测试脚本本身了。k6 是一个灵活的工具,可用于运行多种类型的性能测试。 有关如何编写测试的详细信息,请参阅 k6 文档

在 GitLab CI/CD 中配置测试

当您的 k6 测试脚本准备就绪后,下一步就是在 GitLab CI/CD 中配置负载性能测试作业。最简单的方法是使用 GitLab 自带的 Verify/Load-Performance-Testing.gitlab-ci.yml 模板。

对于大规模的 k6 测试,您需要确保执行实际测试的 GitLab Runner 实例能够处理测试的运行。有关规格详情,请参阅 k6 的指南GitLab.com 的默认共享 Runner的规格可能不足以处理大多数大规模的 k6 测试。

该模板在作业中运行 k6 Docker 容器,并提供了多种自定义作业的方式。

一个配置工作流示例:

  1. 设置 GitLab Runner 以运行 Docker 容器,例如 Docker-in-Docker 工作流

  2. 在您的 .gitlab-ci.yml 文件中配置默认的负载性能测试 CI/CD 作业。 您需要包含该模板并使用 CI/CD 变量对其进行配置:

    include:
      template: Verify/Load-Performance-Testing.gitlab-ci.yml
    
    load_performance:
      variables:
        K6_TEST_FILE: <PROJECT 中 K6 测试文件的路径>

前面的示例在您的 CI/CD 流水线中创建了一个运行 k6 测试的 load_performance 作业。

对于 Kubernetes 设置,应使用不同的模板:Jobs/Load-Performance-Testing.gitlab-ci.yml

k6 有各种选项可以配置其运行测试的方式,例如使用什么吞吐量 (RPS)、测试应运行多长时间等。几乎所有选项都可以在测试脚本本身中配置,但您也可以通过 K6_OPTIONS 变量传递命令行选项。

例如,您可以使用 CLI 选项覆盖测试的持续时间:

  include:
    template: Verify/Load-Performance-Testing.gitlab-ci.yml

  load_performance:
    variables:
      K6_TEST_FILE: <PROJECT 中 K6 测试文件的路径>
      K6_OPTIONS: '--duration 30s'

只有当 k6 的结果通过摘要导出保存为负载性能报告产物时,GitLab 才会在合并请求组件中显示关键性能指标。 始终使用最新的可用负载性能产物,并采用测试中的摘要值。

如果启用了 GitLab Pages,您可以直接在浏览器中查看报告。

在预览应用中进行负载性能测试

前面的 CI/CD YAML 配置示例适用于针对静态环境的测试,但通过一些额外的步骤,它可以扩展以用于预览应用动态环境

最佳方法是将动态 URL 捕获到一个 .env 文件中作为要共享的作业产物,然后使用我们提供的名为 K6_DOCKER_OPTIONS 的自定义 CI/CD 变量来配置 k6 Docker 容器以使用该文件。这样,k6 便可以在脚本中使用标准 JavaScript(例如:http.get(`${__ENV.ENVIRONMENT_URL}`))来使用 .env 文件中的任何环境变量。

例如:

  1. review 作业中:
    1. 捕获动态 URL 并将其保存到 .env 文件中,例如 echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
    2. .env 文件设置为作业产物
  2. load_performance 作业中:
    1. 设置其依赖于 review 作业,以便它继承环境文件。
    2. 使用环境文件的 Docker CLI 选项设置 K6_DOCKER_OPTIONS 变量,例如 --env-file review.env
  3. 配置 k6 测试脚本以在其步骤中使用该环境变量。

您的 .gitlab-ci.yml 文件可能类似于:

stages:
  - deploy
  - performance

include:
  template: Verify/Load-Performance-Testing.gitlab-ci.yml

review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: http://$CI_ENVIRONMENT_SLUG.example.com
  script:
    - run_deploy_script
    - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
  artifacts:
    paths:
      - review.env
  rules:
    - if: $CI_COMMIT_BRANCH  # 根据您的流水线规则进行修改,或根据需要使用 `only/except`。

load_performance:
  dependencies:
    - review
  variables:
    K6_DOCKER_OPTIONS: '--env-file review.env'
  rules:
    - if: $CI_COMMIT_BRANCH  # 根据您的流水线规则进行修改,或根据需要使用 `only/except`。