From 21b2d6da3eae8b1063c64b731b61a6545e37a5ab Mon Sep 17 00:00:00 2001 From: Grant Young Date: Mon, 1 Apr 2024 14:30:53 +0100 Subject: [PATCH 1/4] Adjust Reference Architecture terminology To further highlight that each is designed for the equivalent load correlating to user count --- .../reference_architectures/10k_users.md | 7 ++- .../reference_architectures/1k_users.md | 7 ++- .../reference_architectures/25k_users.md | 7 ++- .../reference_architectures/2k_users.md | 7 ++- .../reference_architectures/3k_users.md | 7 ++- .../reference_architectures/50k_users.md | 7 ++- .../reference_architectures/5k_users.md | 7 ++- .../reference_architectures/index.md | 44 +++++++++---------- 8 files changed, 43 insertions(+), 50 deletions(-) diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index e6a8cba0350842..ac6ee482195888 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 10,000 users +# Reference architecture: 10,000 user load DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 10,000 users -with notable headroom. +This page describes the GitLab reference architecture class designed for the total typical load of up to 10,000 users, both manual and automated, with notable headroom. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -157,7 +156,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 10k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 200 RPS diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index 5499166ded7680..341a42414305ff 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 1,000 users +# Reference architecture: 1,000 user load DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 1,000 users -with notable headroom (non-HA standalone). +This page describes the GitLab reference architecture class designed for the total typical load of up to 1,000 users, both manual and automated, with notable headroom (non-HA standalone). For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -74,7 +73,7 @@ If this applies to you, we strongly recommended referring to the linked document ## Testing methodology The 1k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 20 RPS diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index e2b0b35e03ff91..310f1ae27662fb 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 25,000 users +# Reference architecture: 25,000 user load DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 25,000 users -with notable headroom. +This page describes the GitLab reference architecture class designed for the total typical load of up to 25,000 users, both manual and automated, with notable headroom. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -157,7 +156,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 25k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 500 RPS diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index bdaf4bb7a7ee55..3824f564553f68 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 2,000 users +# Reference architecture: 2,000 user load DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 2,000 users -with notable headroom (non-HA). +This page describes the GitLab reference architecture class designed for the total typical load of up to 2,000 users, both manual and automated, with notable headroom (non-HA). For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -100,7 +99,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 2k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 40 RPS diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index eff1462710b1ff..8f52b0a9d81e2d 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 3,000 users +# Reference architecture: 3,000 user load DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 3,000 users -with notable headroom. +This page describes the GitLab reference architecture class designed for the total typical load of up to 3,000 users, both manual and automated, with notable headroom. This architecture is the smallest one available with HA built in. If you require HA but have a lower user count or total load the [Supported Modifications for lower user counts](#supported-modifications-for-lower-user-counts-ha) @@ -152,7 +151,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 3k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 60 RPS diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index d80bf01e3a7452..961cb6b3faa99a 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 50,000 users +# Reference architecture: 50,000 user load DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 50,000 users -with notable headroom. +This page describes the GitLab reference architecture class designed for the total typical load of up to 50,000 users, both manual and automated, with notable headroom. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -156,7 +155,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 50k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 1000 RPS diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index b9d4bf619cae39..7ed63b27bb710d 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 5,000 users +# Reference architecture: 5,000 user load DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 5,000 users -with notable headroom. +This page describes the GitLab reference architecture class designed for the total typical load of up to 5,000 users, both manual and automated, with notable headroom. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -152,7 +151,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 5k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 100 RPS diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 8b36a31d4101a9..4d0f7e99c0227b 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -12,40 +12,40 @@ DETAILS: **Offering:** Self-managed The GitLab Reference Architectures have been designed and tested by the -GitLab Quality Engineering and Support teams to provide recommended deployments at scale. +GitLab Test Platform and Support teams to provide recommended deployments at scale. ## Available reference architectures -The following Reference Architectures are available as recommended starting points for your environment. +The following Reference Architectures classes are available as recommended starting points for your environment. -The architectures are named in terms of _total_ load, both manual and automated, correlated to user count and based on real data along with substantial headroom added to add additional coverage for most scenarios. +The architectures are named in terms of _total_ typical load, both manual and automated, correlated to user count and based on real data along with substantial headroom added to add additional coverage for most scenarios. -However, it should be noted that in some cases, known heavy scenarios such as [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads) may require adjustments to be made. +Each architecture has been designed to be [scalable and can be adjusted accordingly if required](#scaling-an-environment) by your specific workload. This may be likely in known heavy scenarios such as using [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). For details about what each Reference Architecture has been tested against, see the "Testing Methodology" section of each page. ### GitLab package (Omnibus) -Below is a list of Linux package based architectures: +Below is the list of Linux package based reference architecture classes: -- [Up to 1,000 users](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ -- [Up to 2,000 users](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [Up to 3,000 users](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [Up to 5,000 users](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [Up to 10,000 users](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [Up to 25,000 users](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [Up to 50,000 users](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [1,000 user load](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ +- [2,000 user load](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [3,000 user load](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [5,000 user load](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [10,000 user load](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [25,000 user load](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [50,000 user load](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ### Cloud native hybrid -Below is a list of Cloud Native Hybrid reference architectures, where select recommended components can be run in Kubernetes: +Below is a list of Cloud Native Hybrid reference architecture classes, where select recommended components can be run in Kubernetes: -- [Up to 2,000 users](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [Up to 3,000 users](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [Up to 5,000 users](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [Up to 10,000 users](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [2,000 user load](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [3,000 user load](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [5,000 user load](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [10,000 user load](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [25,000 user load](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [50,000 user load](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ## Before you start @@ -412,7 +412,7 @@ If you choose to use a third party external service: [When selecting to use an external Redis service](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider), it should run a standard, performant, and supported version. Note that this specifically must not be run in [Cluster mode](../../install/requirements.md#redis) as this is unsupported by GitLab. -Redis is primarily single threaded. For the 10,000 user and above Reference Architectures, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. +Redis is primarily single threaded. For the 10,000 user class, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. ### Recommendation notes for Object Storage @@ -477,7 +477,7 @@ For deploying GitLab over multiple data centers or regions we offer [GitLab Geo] ## Validation and test results -The [Quality Engineering team](https://handbook.gitlab.com/handbook/engineering/quality/) +The [Test Platform team](https://handbook.gitlab.com/handbook/engineering/quality/) does regular smoke and performance tests for the reference architectures to ensure they remain compliant. @@ -510,7 +510,7 @@ calculated based on sample customer data. Select the [reference architecture](#available-reference-architectures) that matches your scale. Each endpoint type is tested with the following number of requests per second (RPS) -per 1,000 users: +for the total headroom load of 1,000 users: - API: 20 RPS - Web: 2 RPS -- GitLab From fbb06cbcd56ae89c5a0fd9c441a93e8ecccc4d07 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Tue, 9 Apr 2024 12:53:45 +0100 Subject: [PATCH 2/4] Adjust to more empirical RPS terminology To ensure objective naming is maintained --- .../reference_architectures/10k_users.md | 8 +-- .../reference_architectures/1k_users.md | 10 +-- .../reference_architectures/25k_users.md | 8 +-- .../reference_architectures/2k_users.md | 12 ++-- .../reference_architectures/3k_users.md | 18 +++--- .../reference_architectures/50k_users.md | 8 +-- .../reference_architectures/5k_users.md | 8 +-- .../reference_architectures/index.md | 61 ++++++++++--------- 8 files changed, 67 insertions(+), 66 deletions(-) diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index ac6ee482195888..b65df57cd9512c 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 10,000 user load +# Reference architecture: up to 10,000 users or 200 RPS DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 10,000 users, both manual and automated, with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 200 requests per second (RPS) - The typical peak load of up to 10,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -178,7 +178,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 10,000 users: +To set up GitLab and its components to accommodate up to 10,000 users or 200 RPS: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2397,7 +2397,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 10,000 users we recommend a total Puma worker count of around 80. +For 10,000 users or 200 RPS we recommend a total Puma worker count of around 80. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 20 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index 341a42414305ff..42c117f21061b4 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 1,000 user load +# Reference architecture: up to 10,000 users or 20 RPS DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 1,000 users, both manual and automated, with notable headroom (non-HA standalone). +This page describes the GitLab reference architecture designed to target a peak load of 20 requests per second (RPS) - The typical peak load of up to 1,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -25,7 +25,7 @@ For a full list of reference architectures, see | Users | Configuration | GCP | AWS | Azure | |--------------|-------------------------|----------------|--------------|----------| -| Up to 1,000 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | +| Up to 1,000 or 20 RPS | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | ```plantuml @startuml 1k @@ -120,5 +120,5 @@ Cloud Native Hybrid Reference Architecture is an alternative approach where sele components are deployed in Kubernetes via our official [Helm Charts](https://docs.gitlab.com/charts/), and _stateful_ components are deployed in compute VMs with the Linux package. -The [2k GitLab Cloud Native Hybrid](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (non HA) and [3k GitLab Cloud Native Hybrid](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (HA) reference architectures are the smallest we recommend in Kubernetes. -For environments that serve fewer users, you can lower the node specs. Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md). +The [2k or 40 RPS GitLab Cloud Native Hybrid](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (non HA) and [3k or 60 RPS GitLab Cloud Native Hybrid](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (HA) reference architectures are the smallest we recommend in Kubernetes. +For environments that serve fewer users or a lower RPS, you can lower the node specs. Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md). diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 310f1ae27662fb..3a39977051b606 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 25,000 user load +# Reference architecture: up to 25,000 users or 500 RPS DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 25,000 users, both manual and automated, with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 500 requests per second (RPS) - The typical peak load of up to 25,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -178,7 +178,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 25,000 users: +To set up GitLab and its components to accommodate up to 25,000 users or 500 RPS: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2402,7 +2402,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 25,000 users we recommend a total Puma worker count of around 140. +For 25,000 users or 500 RPS we recommend a total Puma worker count of around 140. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 35 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 3824f564553f68..12045beeb732bd 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -4,20 +4,20 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 2,000 user load +# Reference architecture: up to 2,000 users or 40 RPS DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 2,000 users, both manual and automated, with notable headroom (non-HA). +This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS) - The typical peak load of up to 2,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). > - **Target Load:** API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS > - **High Availability:** No. For a highly-available environment, you can -> follow a modified [3K reference architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha). +> follow a modified [3K or 60 RPS reference architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha). > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) > - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). @@ -121,7 +121,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 2,000 users: +To set up GitLab and its components to accommodate up to 2,000 users or 40 RPS: 1. [Configure the external load balancing node](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -1104,7 +1104,7 @@ section assumes this. NOTE: The 2,000 reference architecture is not a highly-available setup. To achieve HA, -you can follow a modified [3K reference architecture](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative). +you can follow a modified [3K or 60 RPS reference architecture](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative). WARNING: **Gitaly Cluster is not supported to be run in Kubernetes**. @@ -1199,7 +1199,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because two worker processes are created by default and each pod has other small processes running. -For 2,000 users we recommend a total Puma worker count of around 12. +For 2,000 users or 40 RPS we recommend a total Puma worker count of around 12. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 3 Webservice pods with 4 workers per pod and 1 pod per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 8f52b0a9d81e2d..1823bae76cf8ae 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 3,000 user load +# Reference architecture: up to 3,000 users or 60 RPS DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 3,000 users, both manual and automated, with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 60 requests per second (RPS) - The typical peak load of up to 3,000 users, both manual and automated, based on real data with notable headroom added. This architecture is the smallest one available with HA built in. If you require HA but have a lower user count or total load the [Supported Modifications for lower user counts](#supported-modifications-for-lower-user-counts-ha) @@ -173,7 +173,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 3,000 users: +To set up GitLab and its components to accommodate up to 3,000 users or 60 RPS: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2201,18 +2201,18 @@ cluster alongside your instance, read how to ## Supported modifications for lower user counts (HA) -The 3,000 user GitLab reference architecture is the smallest we recommend that achieves High Availability (HA). -However, for environments that need to serve fewer users but maintain HA, there are several +The 3,000 user or 60 RPS GitLab reference architecture is the smallest we recommend that achieves High Availability (HA). +However, for environments that need to serve fewer users or a lower RPS but maintain HA, there are several supported modifications you can make to this architecture to reduce complexity and cost. -It should be noted that to achieve HA with GitLab, the 3,000 user architecture's makeup is ultimately what is -required. Each component has various considerations and rules to follow, and the 3,000 user architecture +It should be noted that to achieve HA with GitLab, the 3,000 user or 60 RPS architecture's makeup is ultimately what is +required. Each component has various considerations and rules to follow, and the architecture meets all of these. Smaller versions of this architecture will be fundamentally the same, but with smaller performance requirements, several modifications can be considered as follows: - Lowering node specs: Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md). - Combining select nodes: Some nodes can be combined to reduce complexity at the cost of some performance: - - GitLab Rails and Sidekiq: Sidekiq nodes can be removed and the component instead enabled on the GitLab Rails nodes. + - GitLab Rails and Sidekiq: Sidekiq nodes can be removed, and the component instead enabled on the GitLab Rails nodes. - PostgreSQL and PgBouncer: PgBouncer nodes could be removed and instead be enabled on PostgreSQL nodes with the Internal Load Balancer pointing to them. However, to enable [Database Load Balancing](../postgresql/database_load_balancing.md), a separate PgBouncer array is still required. - Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). This will also lead to reduced performance. - GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy. @@ -2380,7 +2380,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 3,000 users we recommend a total Puma worker count of around 16. +For 3,000 users or 60 RPS we recommend a total Puma worker count of around 16. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 4 Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 961cb6b3faa99a..d0817e64ac8682 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 50,000 user load +# Reference architecture: up to 50,000 users or 1000 RPS DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 50,000 users, both manual and automated, with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 1000 requests per second (RPS) - The typical peak load of up to 50,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -177,7 +177,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 50,000 users: +To set up GitLab and its components to accommodate up to 50,000 users or 1000 RPS: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2416,7 +2416,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 50,000 users we recommend a total Puma worker count of around 320. +For 50,000 users or 1000 RPS we recommend a total Puma worker count of around 320. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 80 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 7ed63b27bb710d..40071e17164eee 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: 5,000 user load +# Reference architecture: up to 5,000 users or 100 RPS DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture class designed for the total typical load of up to 5,000 users, both manual and automated, with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 100 requests per second (RPS) - The typical peak load of up to 5,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -173,7 +173,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 5,000 users: +To set up GitLab and its components to accommodate up to 5,000 users or 100 RPS: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2355,7 +2355,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 5,000 users we recommend a total Puma worker count of around 40. +For 5,000 users or 100 RPS we recommend a total Puma worker count of around 40. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 10 Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 4d0f7e99c0227b..6cbc9df62e91a9 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -12,40 +12,41 @@ DETAILS: **Offering:** Self-managed The GitLab Reference Architectures have been designed and tested by the -GitLab Test Platform and Support teams to provide recommended deployments at scale. +GitLab Test Platform and Support teams to provide scalable recommended deployments for target loads. ## Available reference architectures -The following Reference Architectures classes are available as recommended starting points for your environment. +The following Reference Architectures are available as recommended starting points for your environment. -The architectures are named in terms of _total_ typical load, both manual and automated, correlated to user count and based on real data along with substantial headroom added to add additional coverage for most scenarios. +The architectures are named in terms of peak load, based on user count or Requests per Second (RPS). Where the latter has been calculated based on average real data of the former with notable headroom added. +NOTE: Each architecture has been designed to be [scalable and can be adjusted accordingly if required](#scaling-an-environment) by your specific workload. This may be likely in known heavy scenarios such as using [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). For details about what each Reference Architecture has been tested against, see the "Testing Methodology" section of each page. ### GitLab package (Omnibus) -Below is the list of Linux package based reference architecture classes: +Below is the list of Linux package based reference architectures: -- [1,000 user load](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ -- [2,000 user load](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [3,000 user load](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [5,000 user load](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [10,000 user load](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [25,000 user load](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [50,000 user load](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [Up to 1,000 users or 20 RPS](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ +- [Up to 2,000 users or 40 RPS](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [Up to 3,000 users or 60 RPS](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [Up to 5,000 users or 100 RPS](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [Up to 10,000 users or 200 RPS](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [Up to 25,000 users or 500 RPS](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [Up to 50,000 users or 1000 RPS](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ### Cloud native hybrid -Below is a list of Cloud Native Hybrid reference architecture classes, where select recommended components can be run in Kubernetes: +Below is a list of Cloud Native Hybrid reference architectures, where select recommended components can be run in Kubernetes: -- [2,000 user load](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [3,000 user load](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [5,000 user load](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [10,000 user load](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [25,000 user load](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [50,000 user load](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [Up to 2,000 users or 40 RPS](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [Up to 3,000 users or 60 RPS](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [Up to 5,000 users or 100 RPS](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [Up to 10,000 users or 200 RPS](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [Up to 25,000 users or 500 RPS](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [Up to 50,000 users or 1000 RPS](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ## Before you start @@ -67,18 +68,18 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the designs you can choose from. It begins with the least complexity, goes to the most, and ends with a decision tree. -### Expected Load (RPS) +### Expected Load (User count or RPS) + +The first thing to check is what the expected peak load is your environment would be expected to serve. -The first thing to check is what the expected load is your environment would be expected to serve. +Each architecture is described in terms of peak User count load or Requests per Second (RPS). As detailed under the "Testing Methodology" section on each page, each architecture is tested +against it's listed RPS for each endpoint type (API, Web, Git) - Which is the typical peak load of the given user count, both manual and automated, with notable headroom. -The Reference Architectures have been designed with substantial headroom by default, but it's recommended to also check the -load of what each architecture has been tested against under the "Testing Methodology" section found on each page, -comparing those values with what load you are expecting against your existing GitLab environment to help select the right Reference Architecture -size. +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/gitlab_metrics.md)) +or estimates, and to select the corresponding architecture as this is the most objective. -Load is given in terms of Requests per Second (RPS) for each endpoint type (API, Web, Git). This information on your existing infrastructure -can typically be surfaced by most reputable monitoring solutions or in some other ways such as load balancer metrics. For example, on existing GitLab environments, -[Prometheus metrics](../monitoring/prometheus/gitlab_metrics.md) such as `gitlab_transaction_duration_seconds` can be used to see this data. +If it's not possible for you to find out the expected peak RPS then it's recommended to select based on User count to start and then monitor the environment +closely to confirm the RPS, whether the architecture is performing and adjust accordingly is necessary. ### Standalone (non-HA) @@ -412,7 +413,7 @@ If you choose to use a third party external service: [When selecting to use an external Redis service](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider), it should run a standard, performant, and supported version. Note that this specifically must not be run in [Cluster mode](../../install/requirements.md#redis) as this is unsupported by GitLab. -Redis is primarily single threaded. For the 10,000 user class, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. +Redis is primarily single threaded. For environments targeting up to 10,000 users / 200 RPS or higher, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. ### Recommendation notes for Object Storage @@ -510,14 +511,14 @@ calculated based on sample customer data. Select the [reference architecture](#available-reference-architectures) that matches your scale. Each endpoint type is tested with the following number of requests per second (RPS) -for the total headroom load of 1,000 users: +per 1,000 users: - API: 20 RPS - Web: 2 RPS - Git (Pull): 2 RPS - Git (Push): 0.4 RPS (rounded to the nearest integer) -The above targets were selected based on real customer data of total environmental loads corresponding to the user count, including CI and other workloads along with additional substantial headroom added. +The above RPS targets were selected based on real customer data of total environmental loads corresponding to the user count, including CI and other workloads along with additional substantial headroom added. ### How to interpret the results -- GitLab From 87a97aaa148c54ad2499b390e8fa0d8ba3dc1f8e Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 12 Apr 2024 08:25:23 +0000 Subject: [PATCH 3/4] Apply 19 suggestion(s) to 8 file(s) Co-authored-by: Kassandra Svoboda Co-authored-by: Achilleas Pipinellis --- .../reference_architectures/10k_users.md | 4 +-- .../reference_architectures/1k_users.md | 4 +-- .../reference_architectures/25k_users.md | 2 +- .../reference_architectures/2k_users.md | 4 +-- .../reference_architectures/3k_users.md | 4 +-- .../reference_architectures/50k_users.md | 4 +-- .../reference_architectures/5k_users.md | 2 +- .../reference_architectures/index.md | 34 +++++++++---------- 8 files changed, 29 insertions(+), 29 deletions(-) diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index b65df57cd9512c..0b657169e1aabc 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 10,000 users or 200 RPS +# Reference architecture: 200 RPS or up to 10,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 200 requests per second (RPS) - The typical peak load of up to 10,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 200 requests per second (RPS), the typical peak load of up to 10,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index 42c117f21061b4..4727f024c1bdf4 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 10,000 users or 20 RPS +# Reference architecture: 20 RPS or up to 1,000 users DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 20 requests per second (RPS) - The typical peak load of up to 1,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 20 requests per second (RPS), the typical peak load of up to 1,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 3a39977051b606..40eecf0082c3f9 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -4,7 +4,7 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 25,000 users or 500 RPS +# Reference architecture: 500 RPS or up to 25,000 users DETAILS: **Tier:** Premium, Ultimate diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 12045beeb732bd..2c7848b767a39f 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 2,000 users or 40 RPS +# Reference architecture: 40 RPS or up to 2,000 users DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS) - The typical peak load of up to 2,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS), the typical peak load of up to 2,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 1823bae76cf8ae..a5aaa427bc0ac0 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 3,000 users or 60 RPS +# Reference architecture: 60 RPS or up to 3,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 60 requests per second (RPS) - The typical peak load of up to 3,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 60 requests per second (RPS), the typical peak load of up to 3,000 users, both manual and automated, based on real data with notable headroom added. This architecture is the smallest one available with HA built in. If you require HA but have a lower user count or total load the [Supported Modifications for lower user counts](#supported-modifications-for-lower-user-counts-ha) diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index d0817e64ac8682..997330a1eba303 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -4,13 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 50,000 users or 1000 RPS +# Reference architecture: 1000 RPS or up to 50,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 1000 requests per second (RPS) - The typical peak load of up to 50,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 1000 requests per second (RPS), the typical peak load of up to 50,000 users, both manual and automated, based on real data with notable headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 40071e17164eee..ff6965c8c43233 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -4,7 +4,7 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 5,000 users or 100 RPS +# Reference architecture: 100 RPS or up to 5,000 users DETAILS: **Tier:** Premium, Ultimate diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 6cbc9df62e91a9..4e77ed6ab75862 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -29,24 +29,24 @@ For details about what each Reference Architecture has been tested against, see Below is the list of Linux package based reference architectures: -- [Up to 1,000 users or 20 RPS](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ -- [Up to 2,000 users or 40 RPS](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [Up to 3,000 users or 60 RPS](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [Up to 5,000 users or 100 RPS](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [Up to 10,000 users or 200 RPS](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [Up to 25,000 users or 500 RPS](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [Up to 50,000 users or 1000 RPS](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [Up to 20 RPS or 1,000 users](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ +- [Up to 40 RPS or 2,000 users](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [Up to 60 RPS or 3,000 users](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [Up to 100 RPS or 5,000 users](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [Up to 200 RPS or 10,000 users](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [Up to 500 RPS or 25,000 users](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [Up to 1000 RPS or 50,000 users](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ### Cloud native hybrid Below is a list of Cloud Native Hybrid reference architectures, where select recommended components can be run in Kubernetes: -- [Up to 2,000 users or 40 RPS](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [Up to 3,000 users or 60 RPS](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [Up to 5,000 users or 100 RPS](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [Up to 10,000 users or 200 RPS](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [Up to 25,000 users or 500 RPS](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [Up to 50,000 users or 1000 RPS](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [40 RPS or Up to 2,000 users](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [60 RPS or Up to 3,000 users](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [100 RPS or Up to 5,000 users](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [200 RPS or Up to 10,000 users](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [500 RPS or Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [1000 RPS or Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ## Before you start @@ -68,17 +68,17 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the designs you can choose from. It begins with the least complexity, goes to the most, and ends with a decision tree. -### Expected Load (User count or RPS) +### Expected Load (RPS or 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 User count load or Requests per Second (RPS). As detailed under the "Testing Methodology" section on each page, each architecture is tested -against it's listed RPS for each endpoint type (API, Web, Git) - Which is the typical peak load of the given user count, both manual and automated, with notable headroom. +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, with notable headroom. 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/gitlab_metrics.md)) or estimates, and to select the corresponding architecture as this is the most objective. -If it's not possible for you to find out the expected peak RPS then it's recommended to select based on User count to start and then monitor the environment +If it's not possible for you to find out the expected peak RPS then it's recommended to select based on user count to start and then monitor the environment closely to confirm the RPS, whether the architecture is performing and adjust accordingly is necessary. ### Standalone (non-HA) -- GitLab From 6581be11a8a40a52b6f9764720f69b94439a13fa Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 12 Apr 2024 11:57:02 +0100 Subject: [PATCH 4/4] Apply new terminology docs wide --- .../backup_large_reference_architectures.md | 2 +- .../runbooks/planned_failover_multi_node.md | 2 +- doc/administration/geo/glossary.md | 2 +- doc/administration/geo/setup/index.md | 2 +- doc/administration/gitaly/index.md | 4 ++-- doc/administration/gitaly/praefect.md | 10 +++++----- doc/administration/postgresql/standalone.md | 2 +- .../reference_architectures/10k_users.md | 6 +++--- .../reference_architectures/1k_users.md | 2 +- .../reference_architectures/25k_users.md | 6 +++--- .../reference_architectures/2k_users.md | 6 +++--- .../reference_architectures/3k_users.md | 10 +++++----- .../reference_architectures/50k_users.md | 6 +++--- .../reference_architectures/5k_users.md | 6 +++--- .../reference_architectures/index.md | 10 +++++----- doc/architecture/blueprints/cells/index.md | 2 +- .../self_managed_costs_and_requirements/index.md | 16 ++++++++-------- doc/development/geo.md | 2 +- doc/development/multi_version_compatibility.md | 2 +- doc/install/aws/index.md | 6 +++--- .../install_gitlab_single_node/index.md | 2 +- doc/update/zero_downtime.md | 2 +- 22 files changed, 54 insertions(+), 54 deletions(-) diff --git a/doc/administration/backup_restore/backup_large_reference_architectures.md b/doc/administration/backup_restore/backup_large_reference_architectures.md index 03998acae4d598..fa2d1b0d8df8a8 100644 --- a/doc/administration/backup_restore/backup_large_reference_architectures.md +++ b/doc/administration/backup_restore/backup_large_reference_architectures.md @@ -18,7 +18,7 @@ This document describes how to: This document is intended for environments using: -- [Linux package (Omnibus) and cloud-native hybrid reference architectures 3,000 users and up](../reference_architectures/index.md) +- [Linux package (Omnibus) and cloud-native hybrid reference architectures 60 RPS / 3,000 users and up](../reference_architectures/index.md) - [Amazon RDS](https://aws.amazon.com/rds/) for PostgreSQL data - [Amazon S3](https://aws.amazon.com/s3/) for object storage - [Object storage](../object_storage.md) to store everything possible, including [blobs](backup_gitlab.md#blobs) and [container registry](backup_gitlab.md#container-registry) diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md index 0b6f486f3c3c11..66351b16479e2e 100644 --- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md +++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md @@ -23,7 +23,7 @@ DETAILS: | Secondaries | One | This runbook guides you through a planned failover of a multi-node Geo site -with one secondary. The following [2000 user reference architecture](../../../../administration/reference_architectures/2k_users.md) is assumed: +with one secondary. The following [40 RPS / 2,000 user reference architecture](../../../../administration/reference_architectures/2k_users.md) is assumed: ```mermaid graph TD diff --git a/doc/administration/geo/glossary.md b/doc/administration/geo/glossary.md index acaffbbaeb86d1..d289279b375843 100644 --- a/doc/administration/geo/glossary.md +++ b/doc/administration/geo/glossary.md @@ -31,7 +31,7 @@ these definitions yet. | Primary site | A GitLab site whose data is being replicated by at least one secondary site. There can only be a single primary site. | Geo-specific | Geo deployment, Primary node | | Secondary site | A GitLab site that is configured to replicate the data of a primary site. There can be one or more secondary sites. | Geo-specific | Geo deployment, Secondary node | | Geo deployment | A collection of two or more GitLab sites with exactly one primary site being replicated by one or more secondary sites. | Geo-specific | | -| Reference architecture | A [specified configuration of GitLab for a number of users](../reference_architectures/index.md), possibly including multiple nodes and multiple sites. | GitLab | | +| Reference architecture | A [specified configuration of GitLab based on Requests per Second or user count](../reference_architectures/index.md), possibly including multiple nodes and multiple sites. | GitLab | | | Promoting | Changing the role of a site from secondary to primary. | Geo-specific | | | Demoting | Changing the role of a site from primary to secondary. | Geo-specific | | | Failover | The entire process that shifts users from a primary Site to a secondary site. This includes promoting a secondary, but contains other parts as well. For example, scheduling maintenance. | Geo-specific | | diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md index 4b69ac4df93841..1f89918c76ac77 100644 --- a/doc/administration/geo/setup/index.md +++ b/doc/administration/geo/setup/index.md @@ -40,7 +40,7 @@ Depending on your GitLab deployment, [additional configuration](#additional-conf ### Multi-node Geo sites -If one or more of your sites is using the [2K reference architecture](../../reference_architectures/2k_users.md) or larger, see +If one or more of your sites is using the [40 RPS / 2,000 user reference architecture](../../reference_architectures/2k_users.md) or larger, see [Configure Geo for multiple nodes](../replication/multiple_servers.md). Depending on your GitLab deployment, [additional configuration](#additional-configuration) for LDAP, object storage, and the container registry might be required. diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 84030675f65b40..0fd0d6523b9806 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -167,9 +167,9 @@ E --> F ### Configure Gitaly Gitaly comes pre-configured with a Linux package installation, which is a configuration -[suitable for up to 1000 users](../reference_architectures/1k_users.md). For: +[suitable for up to 20 RPS / 1,000 users](../reference_architectures/1k_users.md). For: -- Linux package installations for up to 2000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly). +- Linux package installations for up to 40 RPS / 2,000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly). - Self-compiled installations or custom Gitaly installations, see [Configure Gitaly](configure_gitaly.md). GitLab installations for more than 2000 active users performing daily Git write operation may be diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 25bd449808a759..a5d045886204fd 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -14,11 +14,11 @@ Configure Gitaly Cluster using either: - Gitaly Cluster configuration instructions available as part of [reference architectures](../reference_architectures/index.md) for installations of up to: - - [3000 users](../reference_architectures/3k_users.md#configure-gitaly-cluster). - - [5000 users](../reference_architectures/5k_users.md#configure-gitaly-cluster). - - [10,000 users](../reference_architectures/10k_users.md#configure-gitaly-cluster). - - [25,000 users](../reference_architectures/25k_users.md#configure-gitaly-cluster). - - [50,000 users](../reference_architectures/50k_users.md#configure-gitaly-cluster). + - [60 RPS or 3,000 users](../reference_architectures/3k_users.md#configure-gitaly-cluster). + - [100 RPS or 5,000 users](../reference_architectures/5k_users.md#configure-gitaly-cluster). + - [200 RPS or 10,000 users](../reference_architectures/10k_users.md#configure-gitaly-cluster). + - [500 RPS or 25,000 users](../reference_architectures/25k_users.md#configure-gitaly-cluster). + - [1000 RPS or 50,000 users](../reference_architectures/50k_users.md#configure-gitaly-cluster). - The custom configuration instructions that follow on this page. Smaller GitLab installations may need only [Gitaly itself](index.md). diff --git a/doc/administration/postgresql/standalone.md b/doc/administration/postgresql/standalone.md index b1404a919285af..9789fa852dc9e1 100644 --- a/doc/administration/postgresql/standalone.md +++ b/doc/administration/postgresql/standalone.md @@ -13,7 +13,7 @@ DETAILS: If you wish to have your database service hosted separately from your GitLab application servers, you can do this using the PostgreSQL binaries packaged together with the Linux package. This is recommended as part of our -[reference architecture for up to 2,000 users](../reference_architectures/2k_users.md). +[reference architecture for up to 40 RPS or 2,000 users](../reference_architectures/2k_users.md). ## Setting it up diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 0b657169e1aabc..28e95826cf673b 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 200 requests per second (RPS), the typical peak load of up to 10,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 200 requests per second (RPS), the typical peak load of up to 10,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -178,7 +178,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 10,000 users or 200 RPS: +To set up GitLab and its components to accommodate up to 200 RPS or 10,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2397,7 +2397,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 10,000 users or 200 RPS we recommend a total Puma worker count of around 80. +For 200 RPS or 10,000 users we recommend a total Puma worker count of around 80. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 20 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index 4727f024c1bdf4..af324966583649 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 20 requests per second (RPS), the typical peak load of up to 1,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 20 requests per second (RPS), the typical peak load of up to 1,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 40eecf0082c3f9..d8bee9048b9648 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 500 requests per second (RPS) - The typical peak load of up to 25,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 500 requests per second (RPS) - The typical peak load of up to 25,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -178,7 +178,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 25,000 users or 500 RPS: +To set up GitLab and its components to accommodate up to 500 RPS or 25,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2402,7 +2402,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 25,000 users or 500 RPS we recommend a total Puma worker count of around 140. +For 500 RPS or 25,000 users we recommend a total Puma worker count of around 140. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 35 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 2c7848b767a39f..beb17c13eb894a 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS), the typical peak load of up to 2,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS), the typical peak load of up to 2,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -121,7 +121,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 2,000 users or 40 RPS: +To set up GitLab and its components to accommodate up to 40 RPS or 2,000 users: 1. [Configure the external load balancing node](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -1199,7 +1199,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because two worker processes are created by default and each pod has other small processes running. -For 2,000 users or 40 RPS we recommend a total Puma worker count of around 12. +For 40 RPS or 2,000 users we recommend a total Puma worker count of around 12. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 3 Webservice pods with 4 workers per pod and 1 pod per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index a5aaa427bc0ac0..dbfe86461b6deb 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 60 requests per second (RPS), the typical peak load of up to 3,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 60 requests per second (RPS), the typical peak load of up to 3,000 users, both manual and automated, based on real data with headroom added. This architecture is the smallest one available with HA built in. If you require HA but have a lower user count or total load the [Supported Modifications for lower user counts](#supported-modifications-for-lower-user-counts-ha) @@ -173,7 +173,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 3,000 users or 60 RPS: +To set up GitLab and its components to accommodate up to 60 RPS or 3,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2201,11 +2201,11 @@ cluster alongside your instance, read how to ## Supported modifications for lower user counts (HA) -The 3,000 user or 60 RPS GitLab reference architecture is the smallest we recommend that achieves High Availability (HA). +The 60 RPS or 3,000 users GitLab reference architecture is the smallest we recommend that achieves High Availability (HA). However, for environments that need to serve fewer users or a lower RPS but maintain HA, there are several supported modifications you can make to this architecture to reduce complexity and cost. -It should be noted that to achieve HA with GitLab, the 3,000 user or 60 RPS architecture's makeup is ultimately what is +It should be noted that to achieve HA with GitLab, the 60 RPS or 3,000 users architecture's makeup is ultimately what is required. Each component has various considerations and rules to follow, and the architecture meets all of these. Smaller versions of this architecture will be fundamentally the same, but with smaller performance requirements, several modifications can be considered as follows: @@ -2380,7 +2380,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 3,000 users or 60 RPS we recommend a total Puma worker count of around 16. +For 60 RPS or 3,000 users we recommend a total Puma worker count of around 16. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 4 Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 997330a1eba303..dfd63ae3688059 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 1000 requests per second (RPS), the typical peak load of up to 50,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 1000 requests per second (RPS), the typical peak load of up to 50,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -177,7 +177,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 50,000 users or 1000 RPS: +To set up GitLab and its components to accommodate up to 1000 RPS or 50,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2416,7 +2416,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 50,000 users or 1000 RPS we recommend a total Puma worker count of around 320. +For 1000 RPS or 50,000 users we recommend a total Puma worker count of around 320. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 80 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index ff6965c8c43233..7bbc4cb4d579ae 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -10,7 +10,7 @@ DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed to target a peak load of 100 requests per second (RPS) - The typical peak load of up to 5,000 users, both manual and automated, based on real data with notable headroom added. +This page describes the GitLab reference architecture designed to target a peak load of 100 requests per second (RPS) - The typical peak load of up to 5,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -173,7 +173,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 5,000 users or 100 RPS: +To set up GitLab and its components to accommodate up to 100 RPS or 5,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2355,7 +2355,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 5,000 users or 100 RPS we recommend a total Puma worker count of around 40. +For 100 RPS or 5,000 users we recommend a total Puma worker count of around 40. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 10 Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 4e77ed6ab75862..c5874651cd75dd 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -18,7 +18,7 @@ GitLab Test Platform and Support teams to provide scalable recommended deploymen The following Reference Architectures are available as recommended starting points for your environment. -The architectures are named in terms of peak load, based on user count or Requests per Second (RPS). Where the latter has been calculated based on average real data of the former with notable headroom added. +The architectures are named in terms of peak load, based on user count or Requests per Second (RPS). Where the latter has been calculated based on average real data of the former with headroom added. NOTE: Each architecture has been designed to be [scalable and can be adjusted accordingly if required](#scaling-an-environment) by your specific workload. This may be likely in known heavy scenarios such as using [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). @@ -73,7 +73,7 @@ This section explains the designs you can choose from. It begins with the least 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, with notable headroom. +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, with headroom. 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/gitlab_metrics.md)) or estimates, and to select the corresponding architecture as this is the most objective. @@ -171,10 +171,10 @@ graph TD L3A("Do you need HA?
(or Zero-Downtime Upgrades)") L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] - L4A>Recommendation

3K architecture with HA
and supported reductions] + L4A>Recommendation

60 RPS / 3K users architecture with HA
and supported reductions] L4B>Recommendation

Architecture closest to user
count with HA] L4C>Recommendation

Cloud Native Hybrid architecture
closest to user count] - L4D>"Recommendation

Standalone 1K or 2K
architecture with Backups"] + L4D>"Recommendation

Standalone 20 RPS / 1K users or 40 RPS / 2K users
architecture with Backups"] L0A --> L1A L1A --> L2A @@ -413,7 +413,7 @@ If you choose to use a third party external service: [When selecting to use an external Redis service](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider), it should run a standard, performant, and supported version. Note that this specifically must not be run in [Cluster mode](../../install/requirements.md#redis) as this is unsupported by GitLab. -Redis is primarily single threaded. For environments targeting up to 10,000 users / 200 RPS or higher, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. +Redis is primarily single threaded. For environments targeting up to 200 RPS / 10,000 users or higher, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. ### Recommendation notes for Object Storage diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md index 12d9bb7ca1a74a..644facd5a3eb4a 100644 --- a/doc/architecture/blueprints/cells/index.md +++ b/doc/architecture/blueprints/cells/index.md @@ -371,7 +371,7 @@ Cluster-wide features are strongly discouraged because: Services that might initially be cluster-wide are still expected to be split in the future to achieve full service isolation. No feature should be built to depend on such a service (like Elasticsearch). -### Will Cells use the [reference architecture for 50,000 users](../../../administration/reference_architectures/50k_users.md)? +### Will Cells use the [reference architecture for up to 1000 RPS or 50,000 users](../../../administration/reference_architectures/50k_users.md)? The infrastructure team will properly size Cells depending on the load. The Tenant Scale team sees an opportunity to use GitLab Dedicated as a base for Cells deployment. diff --git a/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md b/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md index d8c9c0b25d5ee2..25f503862137ea 100644 --- a/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md +++ b/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md @@ -40,13 +40,13 @@ GitLab Reference Architecture sizes and [costs](../../../../administration/refer | Reference Architecture | ClickHouse type | ClickHouse cost / (GitLab cost + ClickHouse cost) | |-------------|-----------------|-----------------------------------| -| [1k - non HA](https://cloud.google.com/products/calculator#id=a6d6a94a-c7dc-4c22-85c4-7c5747f272ed) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 78.01% | -| [2k - non HA](https://cloud.google.com/products/calculator#id=0d3aff1f-ea3d-43f9-aa59-df49d27c35ca) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 44.50% | -| [3k - HA](https://cloud.google.com/products/calculator/#id=15fc2bd9-5b1c-479d-bc46-d5ce096b8107) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 37.87% | -| [5k - HA](https://cloud.google.com/products/calculator/#id=9a798136-53f2-4c35-be43-8e1e975a6663) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 30.92% | -| [10k - HA](https://cloud.google.com/products/calculator#id=cbe61840-31a1-487f-88fa-631251c2fde5) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 20.47% | -| [25k - HA](https://cloud.google.com/products/calculator#id=b4b8b587-508a-4433-adc8-dc506bbe924f) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 14.30% | -| [50k - HA](https://cloud.google.com/products/calculator/#id=48b4d817-d6cd-44b8-b069-0ba9a5d123ea) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 8.16% | +| [20 RPS / 1k users - non HA](https://cloud.google.com/products/calculator#id=a6d6a94a-c7dc-4c22-85c4-7c5747f272ed) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 78.01% | +| [40 RPS / 2k users- non HA](https://cloud.google.com/products/calculator#id=0d3aff1f-ea3d-43f9-aa59-df49d27c35ca) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 44.50% | +| [60 RPS / 3k users - HA](https://cloud.google.com/products/calculator/#id=15fc2bd9-5b1c-479d-bc46-d5ce096b8107) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 37.87% | +| [100 RPS / 5k users - HA](https://cloud.google.com/products/calculator/#id=9a798136-53f2-4c35-be43-8e1e975a6663) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 30.92% | +| [200 RPS / 10k users - HA](https://cloud.google.com/products/calculator#id=cbe61840-31a1-487f-88fa-631251c2fde5) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 20.47% | +| [500 RPS / 25k users - HA](https://cloud.google.com/products/calculator#id=b4b8b587-508a-4433-adc8-dc506bbe924f) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 14.30% | +| [1000 RPS / 50k users - HA](https://cloud.google.com/products/calculator/#id=48b4d817-d6cd-44b8-b069-0ba9a5d123ea) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 8.16% | NOTE: The ClickHouse Self-Managed component evaluation is the minimum estimation for the costs @@ -57,7 +57,7 @@ The following components increase the cost, and were not considered in the minim - Disk size - depends on data size, hard to estimate. - Disk types - ClickHouse recommends [fast SSDs](https://clickhouse.com/docs/ru/operations/tips#storage-subsystem). - Network usage - ClickHouse recommends using [10 GB network, if possible](https://clickhouse.com/docs/en/operations/tips#network). -- For HA we sum minimum cost across all reference architectures from 3k to 50k users, but HA specs tend to increase with user count. +- For HA we sum minimum cost across all reference architectures from 60 RPS / 3k users to 1000 RPS / 50k users, but HA specs tend to increase with user count. ### Resources diff --git a/doc/development/geo.md b/doc/development/geo.md index e0b4b2a6810318..81390ffc492e79 100644 --- a/doc/development/geo.md +++ b/doc/development/geo.md @@ -689,7 +689,7 @@ After triggering a successful [e2e:package-and-test-ee](testing_guide/end_to_end 1. The `GET:Geo` job can be found and triggered under the `trigger-qa` stage. This pipeline uses [GET](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin up a -[1k](../administration/reference_architectures/1k_users.md) Geo installation, +[20 RPS / 1k users](../administration/reference_architectures/1k_users.md) Geo installation, and run the [`gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa) Geo scenario against the instance. When working on Geo features, it is a good idea to ensure the `qa-geo` job passes in a triggered `GET:Geo pipeline`. diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md index d91e9d10080b86..d1feffb5b465be 100644 --- a/doc/development/multi_version_compatibility.md +++ b/doc/development/multi_version_compatibility.md @@ -93,7 +93,7 @@ These users accept some downtime during the update. Unfortunately we can't ignor ## What kind of components can GitLab be broken down into? -The [50,000 reference architecture](../administration/reference_architectures/50k_users.md) runs GitLab on 48+ nodes. GitLab.com is [bigger than that](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/), plus a portion of the [infrastructure runs on Kubernetes](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture), plus there is a ["canary" stage which receives updates first](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/). +The [1000 RPS or 50,000 user reference architecture](../administration/reference_architectures/50k_users.md) runs GitLab on 48+ nodes. GitLab.com is [bigger than that](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/), plus a portion of the [infrastructure runs on Kubernetes](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture), plus there is a ["canary" stage which receives updates first](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/). But the problem isn't just that there are many nodes. The bigger problem is that a deployment can be divided into different contexts. And GitLab.com is not the only one that does this. Some possible divisions: diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md index 1f15b726804ffa..df6cb7cf3455c9 100644 --- a/doc/install/aws/index.md +++ b/doc/install/aws/index.md @@ -16,16 +16,16 @@ DETAILS: This page offers a walkthrough of a common configuration for GitLab on AWS using the official Linux package. You should customize it to accommodate your needs. NOTE: -For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Linux package installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information. +For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Linux package installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [20 RPS or 1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information. ## Getting started for production-grade GitLab NOTE: This document is an installation guide for a proof of concept instance. It is not a reference architecture and it does not result in a highly available configuration. -Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [2000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [3000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy. +Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [40 RPS or 2,000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [60 RPS or 3,000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy. -GitLab maintains and tests two main types of Reference Architectures. The **Linux package architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Linux package architecture. For example, the 3000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 3000 User Reference Architecture page. +GitLab maintains and tests two main types of Reference Architectures. The **Linux package architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Linux package architecture. For example, the 60 RPS or 3,000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 60 RPS or 3,000 User Reference Architecture page. ### Getting started for production-grade Linux package installations diff --git a/doc/tutorials/install_gitlab_single_node/index.md b/doc/tutorials/install_gitlab_single_node/index.md index 37812b32025fd1..35df29c54721b8 100644 --- a/doc/tutorials/install_gitlab_single_node/index.md +++ b/doc/tutorials/install_gitlab_single_node/index.md @@ -12,7 +12,7 @@ DETAILS: In this tutorial you will learn how to install and securely configure a single node GitLab instance that can accommodate up to -[1,000 users](../../administration/reference_architectures/1k_users.md). +[20 RPS or 1,000 users](../../administration/reference_architectures/1k_users.md). To install a single node GitLab instance and configure it to be secure: diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md index b00569bbded035..025c7811dafbb2 100644 --- a/doc/update/zero_downtime.md +++ b/doc/update/zero_downtime.md @@ -80,7 +80,7 @@ As such, we generally recommend the following order: In this section we'll go through the core process of upgrading a multi-node GitLab environment by sequentially going through each as per the [upgrade order](#upgrade-order) and load balancers / HA mechanisms handle each node going down accordingly. -For the purposes of this guide we'll upgrade a [10,000 Reference Architecture](../administration/reference_architectures/10k_users.md) built with the Linux package. +For the purposes of this guide we'll upgrade a [200 RPS or 10,000 Reference Architecture](../administration/reference_architectures/10k_users.md) built with the Linux package. ### Consul, PostgreSQL, PgBouncer and Redis -- GitLab