概要
Gitlab Performance Tool (gpt) はその名の通り Gitlab のパフォーマンスを測ることができるツールです オンプレで構築した Gitlab がどれくらいの規模まで耐えられるかなどテストすることができます docker でどちらもサクット実行することができます
環境
- Gitlab 13.11.3
- Gitlab helm chart 4.12.0
- docker 19.03.6
- gpt-data-generator 1.0.21
- gitlab-performance-tool
流れと仕組み
GPT は Gitlab API を使って「テストデータの 作成」と「負荷テスト」を行います なので要件としては
- API をコールするためのアクセストークンの取得
- Gitlab の API のエンドポイントにアクセスできる
の 2 つを満たしていれば基本的にはどんな Gitlab 環境にも実行することはできます もし動作しない場合は Gitlab の構築ミスか Gitlab 側のバグになります
root ユーザでパーソナルアクセストークンを作成する
GPT は Gitlab の API を使って負荷テストをします また管理者ユーザ権限が必要になるのでデフォルトで作成される root ユーザを使います
GUI にログインしてユーザの設定からパーソナルアクセストークンを作成しましょう トークンのスコープはすべてオンにします
テストデータの生成
まずは Gitlab にテスト用のプロジェクトやグループを作成します テストデータを作成するためのツールも用意されているのでそれを使います
設定ファイルの作成
GPT は規模に応じてテストのケースを変更することができます 例えば一番小さなテストであれば 1k.json を使います
これをダウンロードして url の部分を変更しましょう それ以外は特に変更の必要はありません
- mkdir config/environments
- vim config/environments/1k.json
{
"environment": {
"name": "1k",
"url": "https://gitlab.example.com",
"user": "root",
"config": {
"latency": "0"
},
"storage_nodes": ["default"]
},
"gpt_data": {
"root_group": "gpt",
"large_projects": {
"group": "large_projects",
"project": "gitlabhq"
},
"many_groups_and_projects": {
"group": "many_groups_and_projects",
"subgroups": 250,
"subgroup_prefix": "gpt-subgroup-",
"projects": 10,
"project_prefix": "gpt-project-"
}
}
}
実行する
ではテストデータの作成用のコンテナを実行します ACCESS_TOKEN に作成した root ユーザのパーソナルアクセストークンを指定します
いくつか質問されますがすべて Yes で OK です また冒頭にも説明しましたが Gitlab の API をコールするので先程 url に指定した Gitlab へはアクセスできる環境で実行してください
- mkdir results
docker run --rm -it \
-e ACCESS_TOKEN=xxxxx \
-v $(pwd)/config:/config \
-v $(pwd)/results:/results \
gitlab/gpt-data-generator --environment 1k.json
成功するとグループやプロジェクトが Gitlab 上に作成されているのが GUI 上でも確認できると思います
注意点としては大きいファイルをアップロードする処理があります そこで nginx など 413 に引っかかる可能性があるので注意しましょう
また大きいプロジェクトのインポートには時間がかかるため 504 が返ってくることがあります 504 が返ってきてもインポートは進んでいるので完了するまで待ちましょう 環境にもよりますが 30 分から 1 時間ほどかかります 504 はリバプロ側の nginx であれば以下で回避できます (server ディレクティブに以下を追記)
send_timeout 3600;
proxy_connect_timeout 3600;
proxy_read_timeout 3600;
proxy_send_timeout 3600;
それでも大きなプロジェクトのインポートに失敗する場合は GUI から tar ファイルを指定して gitlabhq1 という名前のプロジェクト名でインポートしてください またグループを gpt/large_projects 配下に移動してください
helm chart の Gitlab を使っている場合は
nginx-ingress の proxy-body-size の設定を変更する必要があります
--set global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"=0
kubectl get ingress gitlab-webservice-default -n gitlab -o jsonpath={.metadata.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"}
で 0 になっていれば OK です
トラブルシューティング: gitlab-runner がいるとテスト用のパイプラインをインポートできない？
どうやら runner のあるなしは関係なさそうです
パイプラインも 11 個インポートするのですが gitlab-runner がいるとパイプラインが走ってしまうためインポートしてくれません
なので specific-runner/shared-runner はオフにしておきましょう
- Project metadata validation failed: pipelines count '0' should be '11' or higher as specified in the Project Config file.
トラブルシューティング: スペックが足りない
インポートがうまくいかない場合は sidekiq と webservice のメモリと CPU の割当を増やしてみましょう 自分が成功し始めたのはそれぞれに 3GB のメモリを割り当ててから成功するようになりました
そもそもノードに 3GB 以上のメモリがない場合はホストのスペックを上げてから再度試してみてください
負荷の設定ファイルを作成
データの量に合わせて負荷の設定も変えられます 一応おすすめの組み合わせがあるようなので今回はそれに従います
- 1k - 60s_20rps.json (今回はここ)
- 2k - 60s_40rps.json
- 3k - 60s_60rps.json
- 5k - 60s_100rps.json
- 10k - 60s_200rps.json
- 25k - 60s_500rps.json
- 50k - 60s_1000rps.json
設定ファイルはこちらにあるのでダウンロードしましょう 特に編集するところはありません
- mkdir config/options
- vim config/options/60s_20rps.json
{
"stages": [
{ "duration": "5s", "target": 20 },
{ "duration": "50s", "target": 20 },
{ "duration": "5s", "target": 0 }
],
"rps": 20,
"batchPerHost": 0
}
パフォーマンステストの実行
ではパフォーマンステストを実行します
- mkdir tests
docker run --rm -it \
-e ACCESS_TOKEN=xxxxx \
-v $(pwd)/tests:/tests \
-v $(pwd)/config:/config \
-v $(pwd)/results:/results \
gitlab/gitlab-performance-tool --environment 1k.json --options 60s_20rps.json -u
1 時間ほどかかるので待ちましょう 結果は results ディレクトリ配下にあります
ポイントとしては最後の「-u」オプションです これがないと git_push テストなどが行われないのでフルテストを行いたい場合は付与しましょう
結果の見方
Overrall Results Score という値があるのでこれが 100% になっていれば今回テストした規模のユーザ数 (1k.json) はクリアしていることになります
最後に
テストデータを入れるところで今回はハマりました helm chart 版の Gitlab を使ったのですがその場合は MinIO がデフォルトで使われるのでそれの影響かもしれません
