英文:
Self hosted gitlab is slow, how to make it faster?
问题
以下是已翻译的内容：
"我们在AWS上自托管GitLab已经运行了几年，随着一切的增长（存储库大小、看板大小、流水线大小、团队规模），事情明显减慢，以至于我都快发疯了。
仅作参考，以下是一些加载时间。我已经使用性能条（在GitLab中输入p+b）进行性能检查，还检查了浏览器中的网络选项卡以查看完成所需的时间。
- 加载看板，性能检查使用
p+b，最长请求（/api/graphql）：约5秒 - 加载合并请求页面，网络完成：约2秒
- 加载流水线，网络完成：约8秒
我们有哪些选项可以让GitLab再次更快？"
英文:
We've been running self hosted gitlab on AWS for a couple of years now, and with everything growing (repo size, board size, pipeline size, team size), things have slowed down considerably, to point where I'm losing my mind.
Just as a reference, here are some loading times. I've checked both, performance with the performance bar (entering p+b in gitlab) and also checking out the networking tab in the browser and how long it takes to finish.
- Loading the board, perf checked with
p+b, longest request (/api/graphql): ~5s - Loading merge requests page, networking finished: ~2s
- Loading pipelines, networking finished: ~8s
What options do we have to make gitlab faster again?
答案1
得分: 3
以下是已翻译的部分：
"I've done research and surprisingly not that much comes up (don't you people have the same problem?!). The only remedy I've found was changing the instance types, and those do make a difference. So an option, if you have the money to spare, is to get better machines."
"Setup for Performance Tests"
"The slowest to load was the pipelines page and the board, so there I've conducted the speed tests. I took several measurements and averaged the results. On the board I checked the performance bar p+b longest request (/api/graphql) and on the pipelines page I checked the networking tab with caching disabled, until all requests were finished."
"I conducted the tests on a gitlab instance where it was only me playing around and no other team members, so I cannot tell how much the results degrade when more people are working."
"Machine comparison"
| Machine Type | Price | vcpu | RAM | clock speed | Loading Board | Loading Pipelines |
|---|---|---|---|---|---|---|
| t2.large | $70 / month | 2 | 8 | 3.3 | 5s | 5s |
| t3.large | $60 / month | 2 | 8 | 3.1 | 5s | 6s |
| t2.2xlarge | $270 / month | 8 | 32 | 3.3 | 2s | 5.5s |
| z1d.large | $135 / month | 2 | 8 | 4 | 5s | 3.5s |
| m5zn.xlarge | $240 / month | 4 | 16 | 4.5 | 2s | 3.3s |
"It seems that loading the board is rather sensitive to the number of cores or memory while loading the pipelines is sensitive to clock speed. I'm not a pro with the different instance types on AWS, maybe there's some other magic ingredient (low latency networking?) in m5zn that makes it the fastest, those are just the factors that came to my mind."
"I also tested changing the disk from gp2 to gp3 with maximum IOPS and throughput, but that didn't change the performance."
"Conclusion"
"For an all-round ok-ish performance, choose the m5zn.xlarge instance. It is way above the requirements that gitlab claims are necessary, but it speeds up things significantly."
英文:
I've done research and surprisingly not that much comes up (don't you people have the same problem?!). The only remedy I've found was changing the instance types, and those do make a difference. So an option, if you have the money to spare, is to get better machines.
Setup for Performance Tests
The slowest to load was the pipelines page and the board, so there I've conducted the speed tests. I took several measurements and averaged the results. On the board I checked the performance bar p+b longest request (/api/graphql) and on the pipelines page I checked the networking tab with caching disabled, until all requests were finished.
I conducted the tests on a gitlab instance where it was only me playing around and no other team members, so I cannot tell how much the results degrade when more people are working.
Machine comparison
| Machine Type | Price | vcpu | RAM | clock speed | Loading Board | Loading Pipelines |
|---|---|---|---|---|---|---|
| t2.large | $70 / month | 2 | 8 | 3.3 | 5s | 5s |
| t3.large | $60 / month | 2 | 8 | 3.1 | 5s | 6s |
| t2.2xlarge | $270 / month | 8 | 32 | 3.3 | 2s | 5.5s |
| z1d.large | $135 / month | 2 | 8 | 4 | 5s | 3.5s |
| m5zn.xlarge | $240 / month | 4 | 16 | 4.5 | 2s | 3.3s |
It seems that loading the board is rather sensitive to number of cores or memory while loading the pipelines is sensitive to clock speed. I'm not a pro with the different instance types on AWS, maybe there's some other magic ingredient (low latency networking?) in m5zn that makes it the fastest, those are just the factors that came to my mind.
I also tested changing the disk from gp2 to gp3 with maximum IOPS and throughput, but that didn't change the performance.
Conclusion
For an all-round ok-ish performance, choose the m5zn.xlarge instance. It is way above the requirements that gitlab claims are necessary, but it speeds up things significantly.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论