From 29a0102a3b04d8541460b1d8cabbd238edb4b3aa Mon Sep 17 00:00:00 2001 From: Grant Young Date: Wed, 28 Aug 2024 10:28:25 +0100 Subject: [PATCH 1/5] Update Expected Load section in Ref Arch docs Provides some more examples of how to calculate RPS --- doc/administration/reference_architectures/index.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 0a66a4406292be..61067aff7bd3c6 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -68,15 +68,22 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the things to consider when picking a Reference Architecture to start with. -### Expected Load +### Expected Load (RPS / User Count) The first thing to check is what the expected peak load is your environment would be expected to serve. Each architecture is described in terms of peak Requests per Second (RPS) or user count load. As detailed under the "Testing Methodology" section on each page, each architecture is tested against its listed RPS for each endpoint type (API, Web, Git), which is the typical peak load of the given user count, both manual and automated. -It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types, through existing metrics (such as [Prometheus](../monitoring/prometheus/index.md#sample-prometheus-queries)) -or estimates, and to select the corresponding architecture as this is the most objective. +It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types via existing metrics and to select the corresponding architecture as this is the most objective + +Finding out the RPS can depend greatly on the specific environment set up and monitoring stack. Some potential options include: + +- Through [GitLab Prometheus](../monitoring/prometheus/index.md#sample-prometheus-queries) with queries such as `sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController|'}[1m])) by (controller, action)`. +- Through other monitoring solutions. +- Through Load Balancer statistics. + +Contact our [Support team](https://about.gitlab.com/support/) for further guidance if required. #### If in doubt, pick the closest user count and scale accordingly -- GitLab From dbcb93f8d9ed43c13937d60abc5a2d0d6dc957a8 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Wed, 28 Aug 2024 10:32:36 +0100 Subject: [PATCH 2/5] Add Update History lines --- doc/administration/reference_architectures/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 61067aff7bd3c6..13125fff277b8b 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -783,6 +783,8 @@ You can find a full history of changes [on the GitLab project](https://gitlab.co **2024:** +- [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 config on 40 RPS / 2k User page to have correct Redis config. - [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163506): Updated Sidekiq configuration for Prometheus in Monitoring node on 2k. - [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/162144): Added Next Steps breadcrumb section to the pages to help discoverability of additional features. - [2024-05](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/153716): Updated the 60 RPS / 3k User and 100 RPS / 5k User pages to have latest Redis guidance on co-locating Redis Sentinel with Redis itself. -- GitLab From 1c17dab1764d766e5c57e7bc20dd9f4512396028 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Wed, 28 Aug 2024 14:28:02 +0000 Subject: [PATCH 3/5] Apply 3 suggestion(s) to 1 file(s) Co-authored-by: Achilleas Pipinellis --- 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 13125fff277b8b..b10a3a254d6f52 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -68,7 +68,7 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the things to consider when picking a Reference Architecture to start with. -### Expected Load (RPS / User Count) +### Expected load (RPS / user count) The first thing to check is what the expected peak load is your environment would be expected to serve. @@ -77,7 +77,7 @@ against its listed RPS for each endpoint type (API, Web, Git), which is the typi It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types via existing metrics and to select the corresponding architecture as this is the most objective -Finding out the RPS can depend greatly on the specific environment set up and monitoring stack. Some potential options include: +Finding out the RPS can depend greatly on the specific environment setup and monitoring stack. Some potential options include: - Through [GitLab Prometheus](../monitoring/prometheus/index.md#sample-prometheus-queries) with queries such as `sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController|'}[1m])) by (controller, action)`. - Through other monitoring solutions. @@ -784,7 +784,7 @@ You can find a full history of changes [on the GitLab project](https://gitlab.co **2024:** - [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 config on 40 RPS / 2k User page to have correct Redis config. +- [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163478): Updated Redis configuration on 40 RPS / 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. - [2024-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/162144): Added Next Steps breadcrumb section to the pages to help discoverability of additional features. - [2024-05](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/153716): Updated the 60 RPS / 3k User and 100 RPS / 5k User pages to have latest Redis guidance on co-locating Redis Sentinel with Redis itself. -- GitLab From d84ff167c620a9ff345a23d0be38dc754d49cee0 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Wed, 28 Aug 2024 15:30:01 +0100 Subject: [PATCH 4/5] Fix broken sentence --- doc/administration/reference_architectures/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index b10a3a254d6f52..141555917e4df8 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -75,7 +75,7 @@ The first thing to check is what the expected peak load is your environment woul Each architecture is described in terms of peak Requests per Second (RPS) or user count load. As detailed under the "Testing Methodology" section on each page, each architecture is tested against its listed RPS for each endpoint type (API, Web, Git), which is the typical peak load of the given user count, both manual and automated. -It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types via existing metrics and to select the corresponding architecture as this is the most objective +It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types via existing metrics and to select the corresponding architecture as this is the most objective method to determine expected load. Finding out the RPS can depend greatly on the specific environment setup and monitoring stack. Some potential options include: -- GitLab From 0cc7148715e2ff34e2989b52c56a41d1ea4a2b91 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 29 Aug 2024 14:15:46 +0000 Subject: [PATCH 5/5] Apply 1 suggestion(s) to 1 file(s) --- doc/administration/reference_architectures/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 141555917e4df8..3b93d17ea0ff04 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -75,7 +75,7 @@ The first thing to check is what the expected peak load is your environment woul Each architecture is described in terms of peak Requests per Second (RPS) or user count load. As detailed under the "Testing Methodology" section on each page, each architecture is tested against its listed RPS for each endpoint type (API, Web, Git), which is the typical peak load of the given user count, both manual and automated. -It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types via existing metrics and to select the corresponding architecture as this is the most objective method to determine expected load. +It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types through existing metrics and to select the corresponding architecture as this is the most objective method to determine expected load. Finding out the RPS can depend greatly on the specific environment setup and monitoring stack. Some potential options include: -- GitLab