Gitlab性能测试工具--Gitlab Performance Tool（GPT）

  Gitlab的升级迭代是非常快的，为了应对这么快的迭代发布，它也提供了一个非常好用的性能测试工具：Gitlab Performance Tool，简称GPT，通过GPT当我们需要搭建一个线上可靠的Gitlab高性能平台时，可以通过它来测试一些性能。
  GPT虽然好用，但有个限制就是 仅支持12.5及12.5版本后的Gitlab，而且一共推出了两个版本；经测试，两个版本都有同样的限制，这限制主要是其有个项目数据需要导入gitlab，然后基于该项目数据来测试性能。所以这里提供一个绕开的办法，就是如果你已经搭建了12.5之前的版本，并且产生了数据且不好替换的话，可以通过再搭建一个12.5后的版本，然后先导入12.5后的版本，接着在高版本的gitlab导入项目，然后再导出到低版本（比如通过git push --mirror 推出镜像仓库的方式），然后再跑测试脚本即可，我测试在10.8的版本也是可以跑的。

GPT相关文献

  当前可用的版本是v2和v1，本次测试是基于v1来测试，v2相对于v1多了个GPT generator，来生成测试数据而已，其余的大体保持一致：

• 官方doc：https://docs.gitlab.com/ee/user/project/merge_requests/load_performance_testing.html
• v2参考：https://gitlab.com/gitlab-org/quality/performance/-/blob/master/docs/k6.md
• v1参考：https://gitlab.com/gitlab-org/quality/performance/-/blob/v1-master/docs/environment_prep.md

测试环境搭建

  测试基于12.10.6 & GPTv1；步骤：环境搭建 & 测试执行；搭建：

1. 先拉取镜像：gitlab/gitlab-performance-tool:v1
2. 导入测试项目：tarball.tar.gz，官方推介了三种方式：
   1. 通过web界面导入—成功；导入的tar.gz根据参考链接去官网下载即可，另外要记得提前创建群组：qa-perf-testing
   2. 通过脚本导入，需要安装 ruby、gem、bundle等环境 --不建议
   3. 通过github导入 --不建议，因为gitlab一般搭建在内网环境
3. 项目导入后就可以开始配置和执行docker：
   1. 获取root用户的access_token，如果非root，则至少要获取这三个权限：API, read_repository, and write_repository
   2. 配置json文件：主要是下列所列参数，其余的就按照默认的即可，因为官方已经根据他给你的项目配置好了
      1. url：测试的gitlab的url
      2. latency：允许的延迟，默认是0，建议调整；一开始用0测试，因为网络原因报了大量错：time=“2021-03-24T07:36:51Z” level=warning msg=“Error detected: ‘GitLab is not responding’”
      3. repo_storage：默认是gitaly，如果是nfs的存储，则要改为nfs
      4. name：则是你导入时取的项目名
4. 执行docker命令开始跑：
   1. access_token即是上文的root账号
   2. 接下来是挂载项：environment、options、tests、results；–environment指定要读取的json文件，这个文件要存到挂载目录的environment下，不然会默认读他配置的，则会报错
   3. 60s_40rps.json的相关配置看下方，20k.json里面的详细配置看下方
   4. 跑后会得到这样的情况：详细可参考官方提供的录像（https://asciinema.org/a/O96Wc5fyxvLb1IDyviTwbujg8?autoplay=1）

docker run -it -e ACCESS_TOKEN=PMMeVyTAqV7jLpTLJny9 -v /data2/platforms/gitlab-performance-tool/environments:/environments -v /data2/platforms/gitlab-performance-tool/options:/options -v /data2/platforms/gitlab-performance-tool/tests:/tests -v /data2/platforms/gitlab-performance-tool/results:/results gitlab/gitlab-performance-tool:v1 --environment 20k.json --options 60s_40rps.json --tests api_v4_groups_projects.js

5. 当页面出现了大写的K6时就标识启动了，接着会不断弹出info日志标明在逐步触发API

关于option配置的详解

  第二个配置是“选项配置文件”。该文件将设置工具如何运行测试-例如，要运行测试多长时间，有多少用户以及有多少吞吐量。
  该选项配置文件本身是天然的K6配置文件。对于此工具，我们使用它们来设置选项，但也可以根据高级用例的需要，使用它们来设置任何有效的k6选项。
  举例来说，以下是我们的“选项配置文件”之一60s_40rps.json，该文件将测试配置为以40次每秒请求数（RPS）的速度运行60秒：

{
  "stages": [
    { "duration": "5s", "target": 20 },
    { "duration": "10s", "target": 20 },
    { "duration": "5s", "target": 0 }
  ],
  "rps": 20,
  "batchPerHost": 0
}

• stages-定义k6应当运行测试的阶段。设置每个阶段的持续时间以及要使用的用户数（VU）。
• 注意，每个阶段都将比前一个阶段增加，因此在此示例中，方案是在5秒钟内从0个用户增加到2个用户，然后将2个用户维持另外15秒。
• rps -设置k6总计每秒可以发出的最大请求数。
• batchPerHost-设置k6以允许在批量调用中对同一主机的无限请求。
  关于20k.json配置的详解：
  每个设置的详细信息如下。还可以将其中一些配置为环境变量，如下所示：

  环境的详细信息：

• name-环境名称。主要用于输出和结果。（环境变量：ENVIRONMENT_NAME）
• url-环境的完整URL，供所有测试和其他区域使用。（环境变量：ENVIRONMENT_URL）
• config-有关环境的其他详细信息，用于相应地调整测试结果。
• latency-工具将在其中运行与环境之间的网络延迟（以毫秒为单位）。（环境变量：ENVIRONMENT_LATENCY）
• repo_storage-环境用于存储库数据的存储类型。可以是gitaly或nfs。（环境变量：ENVIRONMENT_REPO_STORAGE）

  测试应针对的每个项目的详细信息及其数据。您应该力求在此处和目标环境中提供所有这些详细信息，否则将自动跳过需要这些详细信息的特定测试：

• name -项目名称。
• group -包含预期项目的组的名称。
• branch-项目中可用的大分支的名称。分支的大小应根据您环境的要求进行调整。
• commit_sha-项目中可用的大型提交的SHA参考。提交的大小应根据您环境的要求进行调整。
• commit_sha_signed-项目中可用的已签名提交的SHA参考。
• compare_commits_sha-将比较同一分支上的两个提交的SHA引用。提交之间的差异应调整到您环境的要求。
• file_path -项目中普通大小文件的相对路径。
• dir_path-项目中包含许多文件的目录的相对路径。请注意，该目录必须至少包含100个文件。
• git_push_data-将用于git push测试的Git push数据。如果您使用，则无需更改任何内容gitlabhq。要测试自定义项目或了解有关git push test的更多信息，请参阅Git Push test documentation。提交的大小应根据您环境的要求进行调整。
• branch_current_head_sha-branch_name分支的头提交。
• branch_new_head_sha-branch_current_head_sha在branch_name分支上早于该时间的任何提交SHA 。
• branch_name -现有的分支名称。
• mr_commits_iid-具有大量提交的项目中可用的合并请求的iid。MR的大小应根据您环境的要求进行调整。
• mr_discussions_iid-项目中可用的具有大量讨论/评论的合并请求的ID。MR讨论的大小应根据您环境的要求进行调整。
• search-用于GitLab高级搜索的搜索词列表（需要在特定的环境中进行配置）。每个项目都是针对API和Web UI搜索指定范围的术语。目前，目前支持上面显示的内容。
• projects-项目范围搜索词。
• issues-问题范围搜索字词。
• commits-提交范围搜索字词。
• merge_requests-合并请求范围搜索词。
• milestones-里程碑范围搜索词。
• users-用户范围搜索词。
• issue_iid-项目中存在大量讨论/评论的可用问题的标识。问题讨论的大小应根据您环境的要求进行调整。
• user -用于测试相关端点的有效用户的名称。

总结

  测试工具的搭建非常简单，可以用该工具对内网的gitlab进行测试。