我们已经在 AWS 上运行自托管的 gitlab 几年了，随着一切的增长（回购规模、董事会规模、管道规模、团队规模），事情已经大大放缓，以至于我失去了理智.
作为参考，这里有一些加载时间。我已经检查了性能栏的性能（在 gitlab 中输入 p+b），还检查了浏览器中的网络选项卡以及完成所需的时间。
p+b 进行性能检查，最长请求 (/api/graphql)：~5s我们有什么选择可以让 gitlab 再次变得更快？
【问题讨论】：
标签： gitlab self-hosting gitlab-omnibus
我做了研究，令人惊讶的是并没有那么多（难道你们没有同样的问题吗？！）。我发现的唯一补救方法是更改实例类型，而那些做做出改变。因此，如果您有闲钱，一个选择是购买更好的机器。
加载最慢的是管道页面和板，所以我在那里进行了速度测试。我进行了几次测量并对结果取平均值。在板上，我检查了性能栏 p+b 最长请求 (/api/graphql)，在管道页面上，我检查了禁用缓存的网络选项卡，直到所有请求都完成。
我在一个 gitlab 实例上进行了测试，只有我在玩，没有其他团队成员，所以我不知道当更多的人工作时结果会下降多少。
| 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 |
加载电路板似乎对内核或内存的数量相当敏感，而加载管道对时钟速度敏感。我不是 AWS 上不同实例类型的专家，也许 m5zn 中有一些其他神奇的成分使其成为最快的，这些只是我想到的因素。
要获得全面的 ok-ish 性能，请选择 m5zn.xlarge 实例。它远远高于 gitlab 声称的必要要求，但它显着加快了速度。
【讨论】：