From 89970264763763e1d701bf79eb1e81bfc6875c6a Mon Sep 17 00:00:00 2001 From: Grant Young Date: Mon, 16 Dec 2024 14:05:23 +0000 Subject: [PATCH 1/4] Add start large guidance to Ref Arch docs --- .../reference_architectures/index.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index ca72be46c400fe..afa28f56a154ee 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -170,8 +170,13 @@ To determine which architecture to pick for the expected load, see the following NOTE: Before you select an initial architecture, review this section thoroughly. Consider other factors such as High Availability (HA) or use of large monorepos, as they may impact the choice beyond just RPS or user count. -NOTE: -After you select an initial reference architecture, you can [scale up and down](#scaling-an-environment) according to your needs if metrics support. +#### If in doubt - Start large, monitor and scale down + +If you're uncertain about the required environment size - Consider starting with a larger size, monitoring and [scaling down](#scaling-an-environment) accordingly if the metrics support. + +This is a prudent approach for situations such as when you can't determine RPS or if environment load could be atypically higher than expected, such as due to [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). + +For example, if you have 3,000 users but also know that there's automation at play that would significantly increase the concurrent load then you could start with a 100 RPS / 5k User class environment to start, monitor it and scaled down components wholesale or iteratively if the metrics support. ### Standalone (non-HA) @@ -235,7 +240,7 @@ same architecture as the primary or if each site is configured for HA. [Large monorepos](#large-monorepos) or significant [additional workloads](#additional-workloads) can affect the performance of the environment notably. Some adjustments may be required depending on the context. -If this situation applies to you, reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) +If this situation applies to you, reach out to your GitLab representative or our [Support team](https://about.gitlab.com/support/) for further guidance. ### Cloud provider services @@ -281,7 +286,7 @@ graph TD L4C ~~~ L5A L4D ~~~ L5A - L5B("Do you have Large Monorepos or expect
to have substantial additional workloads?") --> |Yes| L6B>Additional Recommendation

Contact Customer Success Manager or Support] + L5B("Do you have Large Monorepos or expect
to have substantial additional workloads?") --> |Yes| L6B>Additional Recommendations

Start large, monitor and scale down

Contact GitLab representative or Support] L4A ~~~ L5B L4B ~~~ L5B L4C ~~~ L5B @@ -343,7 +348,7 @@ Their presence and how they are used can put a significant strain on the entire The performance implications are largely software in nature. Additional hardware resources lead to diminishing returns. WARNING: -If this applies to you, we strongly recommend you follow the linked documentation and reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. +If this applies to you, we strongly recommend you follow the linked documentation and reach out to your GitLab representative or our [Support team](https://about.gitlab.com/support/) for further guidance. Large monorepos come with notable cost. If you have such a repository, follow these guidance to ensure good performance and to keep costs in check: @@ -371,7 +376,7 @@ You may need to adjust the suggested specifications to compensate if you use: - [System hooks](../system_hooks.md). Generally, you should have robust monitoring in place to measure the impact of any additional workloads to -inform any changes needed to be made. Reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) +inform any changes needed to be made. Reach out to your GitLab representative or our [Support team](https://about.gitlab.com/support/) for further guidance. ### Load Balancers -- GitLab From 21b7612824afb1235a402c823cec1fc7e7d322f6 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Mon, 16 Dec 2024 14:08:23 +0000 Subject: [PATCH 2/4] Further refinements --- doc/administration/reference_architectures/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index afa28f56a154ee..09f910a176e6d5 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -11,8 +11,7 @@ DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -The GitLab reference architectures provide recommended scalable and elastic deployments as starting points for target loads. They are designed and tested by the -GitLab Test Platform and Support teams. +The GitLab reference architectures provide recommended scalable and elastic environment sizes. ## Available reference architectures @@ -79,6 +78,7 @@ Each architecture is designed to handle specific RPS targets for different types Finding out the RPS can depend notably on the specific environment setup and monitoring stack. Some potential options include: - [GitLab Prometheus](../monitoring/prometheus/index.md#sample-prometheus-queries) with queries like `sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController|'}[1m])) by (controller, action)`. +- [`get-rps` script](https://gitlab.com/gitlab-com/support/toolbox/dotfiles/-/blob/main/scripts/get-rps.rb?ref_type=heads) from GitLab Support. - Other monitoring solutions. - Load Balancer statistics. @@ -172,7 +172,7 @@ Before you select an initial architecture, review this section thoroughly. Consi #### If in doubt - Start large, monitor and scale down -If you're uncertain about the required environment size - Consider starting with a larger size, monitoring and [scaling down](#scaling-an-environment) accordingly if the metrics support. +If you're uncertain about the required environment size - Consider starting with a larger size, [monitoring](#monitoring) and [scaling down](#scaling-an-environment) accordingly if the metrics support. This is a prudent approach for situations such as when you can't determine RPS or if environment load could be atypically higher than expected, such as due to [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). -- GitLab From acd1b35d58b5e707d1d6912342e6a7e608db4053 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Mon, 16 Dec 2024 15:14:13 +0000 Subject: [PATCH 3/4] Add update history note --- doc/administration/reference_architectures/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 09f910a176e6d5..72b3a511a8406c 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -863,6 +863,7 @@ You can find a full history of changes [on the GitLab project](https://gitlab.co **2024:** +- [2024-12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175854): Added _Start Large_ section as further guidance for choosing initial sizing. - [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/164181): Updated Expected Load section with some more examples on how to calculate RPS. - [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163478): Updated Redis configuration on 40 RPS or 2k User page to have correct Redis configuration. - [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163506): Updated Sidekiq configuration for Prometheus in Monitoring node on 2k. -- GitLab From 8d28d668c343a7178b8f61b8d2469464f4ca89bf Mon Sep 17 00:00:00 2001 From: Grant Young Date: Tue, 17 Dec 2024 13:33:28 +0000 Subject: [PATCH 4/4] Apply 1 suggestion(s) to 1 file(s) Co-authored-by: Achilleas Pipinellis --- doc/administration/reference_architectures/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 72b3a511a8406c..ababf649757042 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -170,13 +170,13 @@ To determine which architecture to pick for the expected load, see the following NOTE: Before you select an initial architecture, review this section thoroughly. Consider other factors such as High Availability (HA) or use of large monorepos, as they may impact the choice beyond just RPS or user count. -#### If in doubt - Start large, monitor and scale down +#### If in doubt, start large, monitor, and then scale down -If you're uncertain about the required environment size - Consider starting with a larger size, [monitoring](#monitoring) and [scaling down](#scaling-an-environment) accordingly if the metrics support. +If you're uncertain about the required environment size, consider starting with a larger size, [monitoring](#monitoring) it, and then [scaling down](#scaling-an-environment) accordingly if the metrics support your situation. -This is a prudent approach for situations such as when you can't determine RPS or if environment load could be atypically higher than expected, such as due to [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). +Starting large and then scaling down is a prudent approach when you can't determine RPS, or if the environment load could be atypically higher than expected, mostly due to [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). -For example, if you have 3,000 users but also know that there's automation at play that would significantly increase the concurrent load then you could start with a 100 RPS / 5k User class environment to start, monitor it and scaled down components wholesale or iteratively if the metrics support. +For example, if you have 3,000 users but also know that there's automation at play that would significantly increase the concurrent load, then you could start with a 100 RPS / 5k User class environment, monitor it, and if the metrics support it, scale down all components at once or one by one. ### Standalone (non-HA) -- GitLab