Load Performance Testing

原文：https://docs.gitlab.com/ee/user/project/merge_requests/load_performance_testing.html

Load Performance Testing

Introduced in GitLab Premium 13.2.

使用负载性能测试，您可以在GitLab CI / CD 中测试任何待处理代码更改对应用程序后端的影响.

GitLab 使用免费的开源工具k6来测量负载下应用程序的系统性能.

Unlike Browser Performance Testing, which is used to measure how web sites perform in client browsers, Load Performance Testing can be used to perform various types of load tests against application endpoints such as APIs, Web Controllers, and so on. This can be used to test how the backend or the server performs at scale.

例如，您可以使用负载性能测试对应用程序中流行的 API 端点执行许多并发 GET 调用，以查看其性能.

How Load Performance Testing works

首先，在您的.gitlab-ci.yml文件中定义一个作业，以生成” 负载性能”报告工件 . GitLab 会检查此报告，比较源分支和目标分支之间的关键负载性能指标，然后在合并请求小部件中显示信息：

Load Performance Widget

接下来，您需要配置测试环境并编写 k6 测试.

测试完成后，合并请求窗口小部件显示的关键性能指标是：

  • 支票：在 k6 测试中配置的支票的通过率.
  • TTFB P90: The 90th percentile of how long it took to start receiving responses, aka the Time to First Byte (TTFB).
  • TTFB P95：TTFB 的第 95 个百分点.
  • RPS：测试能够达到的平均每秒请求数（RPS）.

注意：如果”负载性能”报告没有可比较的数据，例如，当您第一次在.gitlab-ci.yml添加”负载性能”作业时，”负载性能”报告小部件将不会显示. 它必须在目标分支（例如master ）上至少运行一次，然后才能在针对该分支的合并请求中显示.

Configure the Load Performance Testing job

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

  • 确定测试参数，例如吞吐量，等等.
  • 设置目标测试环境以进行负载性能测试.
  • 设计并编写 k6 测试.

Determine the test parameters

您需要做的第一件事是确定要运行的负载测试的类型以及运行方式（例如，用户数量，吞吐量等）.

请参阅k6 文档 ，尤其是k6 测试指南 ，以获取有关上述内容及更多内容的指南.

Test Environment setup

负载性能测试的大部分工作是为高负载准备目标测试环境. 您应该确保它能够处理将要测试的吞吐量 .

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

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

Write the load performance test

准备好环境后，您可以编写 k6 测试本身. k6 是一种灵活的工具，可用于运行多种性能测试 . 有关如何编写测试的详细信息，请参阅k6 文档 .

Configure the test in GitLab CI/CD

准备好 k6 测试后，下一步就是在 GitLab CI / CD 中配置负载性能测试作业. 最简单的方法是使用 GitLab 随附的Verify/Load-Performance-Testing.gitlab-ci.yml模板.

注意：对于大型 k6 测试，您需要确保执行实际测试的 GitLab Runner 实例能够处理运行测试. 有关规格的详细信息，请参阅k6 的指南 . 默认的共享 GitLab.com 运行程序可能没有足够的规格来处理大多数大型 k6 测试.

该模板在作业中运行k6 Docker 容器 ，并提供了几种自定义作业的方法.

配置工作流程示例：

  1. 设置一个可以运行 Docker 容器的 GitLab Runner，例如使用Docker-in-Docker 工作流的 Runner.

  2. 在.gitlab-ci.yml文件中配置默认​​的 Load Performance Testing CI 作业. 您需要包括模板并使用变量进行配置：

    1. include:
    2.   template: Verify/Load-Performance-Testing.gitlab-ci.yml
    4. load_performance:
    5.   variables:
    6.     K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>

上面的示例在运行 k6 测试的 CI / CD 管道中创建了一个load_performance作业.

注意：对于 Kubernetes 设置，应使用其他模板： Jobs/Load-Performance-Testing.gitlab-ci.yml .

k6 具有各种选项来配置它将如何运行测试，例如运行什么吞吐量（RPS），测试应该运行多长时间等等. 几乎所有选项都可以在测试本身中进行配置，但是您也可以通过K6_OPTIONS变量传递命令行选项.

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

  1.  include:
  2.     template: Verify/Load-Performance-Testing.gitlab-ci.yml
  4.   load_performance:
  5.     variables:
  6.       K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
  7.       K6_OPTIONS: '--duration  30s'

如果 k6 的结果通过摘要导出保存为” 负载性能”报告工件，则 GitLab 仅在 MR 小部件中显示关键性能指标. 始终使用最新的可用负载性能工件.

如果启用了GitLab Pages，则可以直接在浏览器中查看报告.

Load Performance testing in Review Apps

上面的 CI / CD YAML 配置示例适用于针对静态环境进行测试，但是可以通过一些额外的步骤将其扩展为与审阅应用程序或动态环境一起使用.

最好的方法是将动态 URL 捕获到一个自定义环境变量中，然后由load_performance作业继承该load_performance . 然后应将要运行的 k6 测试脚本配置为使用该环境 URL，例如： http.get(${__ENV.ENVIRONMENT_URL}) .

例如：

  1. 在review工作中：
    1. 捕获动态 URL 并将其保存到.env文件，例如echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env .
    2. 将.env文件设置为artifacts:reports:dotenv report .
  2. 将load_performance作业设置为依赖于审阅作业，以便它继承环境变量.
  3. 配置 k6 测试脚本以在其步骤中使用环境变量.

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

  1. stages:
  2.   - deploy
  3.   - performance
  5. include:
  6.   template: Verify/Load-Performance-Testing.gitlab-ci.yml
  8. review:
  9.   stage: deploy
  10.   environment:
  11.     name: review/$CI_COMMIT_REF_NAME
  12.     url: http://$CI_ENVIRONMENT_SLUG.example.com
  13.   script:
  14.     - run_deploy_script
  15.     - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
  16.   artifacts:
  17.     reports:
  18.       dotenv:
  19.         review.env
  20.   rules:
  21.     - if: '$CI_COMMIT_BRANCH'  # Modify to match your pipeline rules, or use `only/except` if needed.
  23. load_performance:
  24.   dependencies:
  25.     - review
  26.   rules:
  27.     - if: '$CI_COMMIT_BRANCH'  # Modify to match your pipeline rules, or use `only/except` if needed.