diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 16f1f11a6b13e0b1fb7cb1fd973b5407f8656c81..2d42b8a6be31f7621d4b17701ca14719d41e90ea 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -6,18 +6,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 10,000 users **(PREMIUM SELF)** -This page describes GitLab reference architecture for up to 10,000 users. For a -full list of reference architectures, see +This page describes the GitLab reference architecture designed for the load of up to 10,000 users +with notable headroom. + +For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). -> - **Supported users (approximate):** 10,000 +NOTE: +Before deploying this architecture it's recommended to read through the [main documentation](index.md) first, +specifically the [Before you start](index.md#before-you-start) and [Deciding which architecture to use](index.md#deciding-which-architecture-to-use) sections. + +> - **Target load:** API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS > - **High Availability:** Yes ([Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution for HA) > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid Alternative:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/10k)** -> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). +> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use) | Service | Nodes | Configuration | GCP | AWS | |------------------------------------------|-------|-------------------------|------------------|----------------| @@ -144,6 +147,27 @@ monitor .[#7FFFD4,norank]u--> elb Before starting, see the [requirements](index.md#requirements) for reference architectures. +## 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 +against the following endpoint throughput targets: + +- API: 200 RPS +- Web: 20 RPS +- Git (Pull): 20 RPS +- Git (Push): 4 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup components To set up GitLab and its components to accommodate up to 10,000 users: diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index 2f7c8209a4464f2ed7661c1d571b279a4b7a31ff..362da0bd7c6c1516349223fd75c927401cee7604 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -6,24 +6,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 1,000 users **(FREE SELF)** -This page describes GitLab reference architecture for up to 1,000 users. For a -full list of reference architectures, see -[Available reference architectures](index.md#available-reference-architectures). +This page describes the GitLab reference architecture designed for the load of up to 1,000 users +with notable headroom (non-HA standalone). -If you are serving up to 1,000 users, and you don't have strict availability -requirements, a [standalone](index.md#standalone-non-ha) single-node solution with -frequent backups is appropriate for -many organizations. +For a full list of reference architectures, see +[Available reference architectures](index.md#available-reference-architectures). -> - **Supported users (approximate):** 1,000 +> - **Target Load:** API: 20 RPS, Web: 2 RPS, Git (Pull): 2 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). > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid:** No. For a cloud native hybrid environment, you > can follow a [modified hybrid reference architecture](#cloud-native-hybrid-reference-architecture-with-helm-charts). -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/1k)** > - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). | Users | Configuration | GCP | AWS | Azure | @@ -73,6 +67,27 @@ WARNING: **However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact the performance of the environment and further adjustments may be required.** If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. +## 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 +against the following endpoint throughput targets: + +- API: 20 RPS +- Web: 2 RPS +- Git (Pull): 2 RPS +- Git (Push): 1 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup instructions To install GitLab for this default reference architecture, use the standard diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 1745fb55b22cd0ec50992e0dee8d0a6d2808ba93..b3c56c371b93f43a6f704828f294b9d4338cf40a 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -6,18 +6,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 25,000 users **(PREMIUM SELF)** -This page describes GitLab reference architecture for up to 25,000 users. For a -full list of reference architectures, see +This page describes the GitLab reference architecture designed for the load of up to 25,000 users +with notable headroom. + +For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). -> - **Supported users (approximate):** 25,000 +NOTE: +Before deploying this architecture it's recommended to read through the [main documentation](index.md) first, +specifically the [Before you start](index.md#before-you-start) and [Deciding which architecture to use](index.md#deciding-which-architecture-to-use) sections. + +> - **Target load:** API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS > - **High Availability:** Yes ([Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution for HA) > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid Alternative:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/25k)** -> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). +> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use) | Service | Nodes | Configuration | GCP | AWS | |------------------------------------------|-------|-------------------------|------------------|--------------| @@ -144,6 +147,27 @@ monitor .[#7FFFD4,norank]u--> elb Before starting, see the [requirements](index.md#requirements) for reference architectures. +## 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 +against the following endpoint throughput targets: + +- API: 500 RPS +- Web: 50 RPS +- Git (Pull): 50 RPS +- Git (Push): 10 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup components To set up GitLab and its components to accommodate up to 25,000 users: diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 6528301ae149cbd228ee28b5fac7040e12afb671..fb8b9d8de45e79a429d8798fa6fe7565ff43b077 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -6,18 +6,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 2,000 users **(FREE SELF)** -This page describes GitLab reference architecture for up to 2,000 users. +This page describes the GitLab reference architecture designed for the load of up to 2,000 users +with notable headroom (non-HA). + For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). -> - **Supported users (approximate):** 2,000 +> - **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). > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/2k)** > - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). | Service | Nodes | Configuration | GCP | AWS | Azure | @@ -81,6 +80,27 @@ monitor .[#7FFFD4,norank]u--> elb Before starting, see the [requirements](index.md#requirements) for reference architectures. +## 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 +against the following endpoint throughput targets: + +- API: 40 RPS +- Web: 4 RPS +- Git (Pull): 4 RPS +- Git (Push): 1 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup components To set up GitLab and its components to accommodate up to 2,000 users: diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 80e2ed7683913538c5a93232019c51f91ddd23dd..3de21f21716dc6fee5e31a06c9ccd6568e422c1f 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -6,27 +6,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 3,000 users **(PREMIUM SELF)** -This GitLab reference architecture can help you deploy GitLab to up to 3,000 -users, and then maintain uptime and access for those users. You can also use -this architecture to provide improved GitLab uptime and availability for fewer -than 3,000 users. For fewer users, reduce the stated node sizes as needed. +This page describes the GitLab reference architecture designed for the load of up to 3,000 users +with notable headroom. -If maintaining a high level of uptime for your GitLab environment isn't a -requirement, or if you don't have the expertise to maintain this sort of -environment, we recommend using the non-HA [2,000-user reference architecture](2k_users.md) -for your GitLab installation. If HA is still a requirement, there's several supported -tweaks you can make to this architecture to reduce complexity as detailed here. +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) +section details how to reduce this architecture's size while maintaining HA. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). -> - **Supported users (approximate):** 3,000 +> - **Target Load:** 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS > - **High Availability:** Yes, although [Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid Alternative:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/3k)** > - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). | Service | Nodes | Configuration | GCP | AWS | @@ -149,6 +142,27 @@ monitor .[#7FFFD4,norank]u--> elb Before starting, see the [requirements](index.md#requirements) for reference architectures. +## 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 +against the following endpoint throughput targets: + +- API: 60 RPS +- Web: 6 RPS +- Git (Pull): 6 RPS +- Git (Push): 1 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup components To set up GitLab and its components to accommodate up to 3,000 users: diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index b0ca172893e61b78d2ac223319dc09965f829c74..361deaf939d2d0be04f963df1b17cdeb13528882 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -6,18 +6,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 50,000 users **(PREMIUM SELF)** -This page describes GitLab reference architecture for up to 50,000 users. For a -full list of reference architectures, see +This page describes the GitLab reference architecture designed for the load of up to 50,000 users +with notable headroom. + +For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). -> - **Supported users (approximate):** 50,000 +NOTE: +Before deploying this architecture it's recommended to read through the [main documentation](index.md) first, +specifically the [Before you start](index.md#before-you-start) and [Deciding which architecture to use](index.md#deciding-which-architecture-to-use) sections. + +> - **Target load:** API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS > - **High Availability:** Yes ([Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution for HA) > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid Alternative:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/50k)** -> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). +> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use) | Service | Nodes | Configuration | GCP | AWS | |------------------------------------------|-------|-------------------------|------------------|---------------| @@ -144,6 +147,27 @@ monitor .[#7FFFD4,norank]u--> elb Before starting, see the [requirements](index.md#requirements) for reference architectures. +## 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 +against the following endpoint throughput targets: + +- API: 1000 RPS +- Web: 100 RPS +- Git (Pull): 100 RPS +- Git (Push): 20 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup components To set up GitLab and its components to accommodate up to 50,000 users: diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 5e6387359d80851adcfebd8f0c44a122b8e9f588..663bf9e5216e5fc1e6deb4dbbbc7699e0129b403 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -6,25 +6,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Reference architecture: up to 5,000 users **(PREMIUM SELF)** -This page describes GitLab reference architecture for up to 5,000 users. For a -full list of reference architectures, see +This page describes the GitLab reference architecture designed for the load of up to 5,000 users +with notable headroom. + +For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). NOTE: -This reference architecture is designed to help your organization achieve a -highly-available GitLab deployment. If you do not have the expertise or need to -maintain a highly-available environment, you can have a simpler and less -costly-to-operate environment by using the -[2,000-user reference architecture](2k_users.md). +Before deploying this architecture it's recommended to read through the [main documentation](index.md) first, +specifically the [Before you start](index.md#before-you-start) and [Deciding which architecture to use](index.md#deciding-which-architecture-to-use) sections. -> - **Supported users (approximate):** 5,000 +> - **Target load:** API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS > - **High Availability:** Yes ([Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution for HA) > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid Alternative:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -> - **Validation and test results:** The Quality Engineering team does [regular smoke and performance tests](index.md#validation-and-test-results) to ensure the reference architectures remain compliant -> - **Test requests per second (RPS) rates:** API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS -> - **[Latest Results](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest/5k)** -> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). +> - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use) | Service | Nodes | Configuration | GCP | AWS | |-------------------------------------------|-------|-------------------------|-----------------|--------------| @@ -146,6 +142,27 @@ monitor .[#7FFFD4,norank]u--> elb Before starting, see the [requirements](index.md#requirements) for reference architectures. +## 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 +against the following endpoint throughput targets: + +- API: 100 RPS +- Web: 10 RPS +- Git (Pull): 10 RPS +- Git (Push): 2 RPS + +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. + +If you have metrics to suggest that you have regularly higher throughput against the above endpoint targets, [large monorepos](index.md#large-monorepos) +or notable [additional workloads](index.md#additional-workloads) these can notably impact the performance environment and [further adjustments may be required](index.md#scaling-an-environment). +If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. + +Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. +The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). + ## Setup components To set up GitLab and its components to accommodate up to 5,000 users: diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index e2fc425b5362b1a65531febde729734d051471e2..fcbfaf460097470e259bfe41561d520976b4b77b 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -12,36 +12,37 @@ GitLab Quality Engineering and Support teams to provide recommended deployments ## Available reference architectures -Depending on your workflow, the following recommended reference architectures -may need to be adapted accordingly. Your workload is influenced by factors -including how active your users are, how much automation you use, mirroring, -and repository/change size. Additionally, the displayed memory values are -provided by [GCP machine types](https://cloud.google.com/compute/docs/machine-resource). -For different cloud vendors, attempt to select options that best match the -provided architecture. +The following Reference Architectures are available as recommended starting points for your environment. + +The architectures are named in terms of user count, which in this case means the architecture is designed against +the _total_ load that comes with such a user count based on real data along with substantial headroom added to cover most scenarios such as CI or other automated workloads. + +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. + +For each Reference Architecture, the details of what they have been tested against can be found respectively in the "Testing Methodology" section of each page. ### GitLab package (Omnibus) -The following reference architectures, where the GitLab package is used, are available: +Below is a list of Linux package based architectures: -- [Up to 1,000 users](1k_users.md) -- [Up to 2,000 users](2k_users.md) -- [Up to 3,000 users](3k_users.md) -- [Up to 5,000 users](5k_users.md) -- [Up to 10,000 users](10k_users.md) -- [Up to 25,000 users](25k_users.md) -- [Up to 50,000 users](50k_users.md) +- [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_ ### Cloud native hybrid -The following Cloud Native Hybrid reference architectures, where select recommended components can be run in Kubernetes, are available: +Below is a list of Cloud Native Hybrid reference architectures, 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) -- [Up to 3,000 users](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -- [Up to 5,000 users](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -- [Up to 10,000 users](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -- [Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) -- [Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) +- [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_ ## Before you start @@ -63,6 +64,19 @@ 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) + +The first thing to check is what the expected load is your environment would be expected to serve. + +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. + +Load is given in terms of Requests per Section (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. + ### Standalone (non-HA) For environments serving 2,000 or fewer users, we generally recommend a standalone approach by deploying a non-highly available single or multi-node environment. With this approach, you can employ strategies such as [automated backups](../../administration/backup_restore/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of RPO / RTO while avoiding the complexities that come with HA. @@ -144,10 +158,11 @@ Below you can find the above guidance in the form of a decision tree. It's recom ```mermaid %%{init: { 'theme': 'base' } }%% graph TD - L1A(What Reference Architecture should I use?) + L0A(What Reference Architecture should I use?) + L1A(What is your expected load?) - L2A(3,000 users or more?) - L2B(2,000 users or less?) + L2A("Equivalent to 3,000 users or more?") + L2B("Equivalent to 2,000 users or less?") L3A("Do you need HA?
(or Zero-Downtime Upgrades)") L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] @@ -157,6 +172,7 @@ graph TD L4C>Recommendation

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

Standalone 1K or 2K
architecture with Backups"] + L0A --> L1A L1A --> L2A L1A --> L2B L2A -->|Yes| L3B @@ -664,15 +680,28 @@ You should upgrade a Reference Architecture in the same order as you created it. ### Scaling an environment -Scaling a GitLab environment is designed to be as seamless as possible. +Scaling a GitLab environment is designed to be as flexible and seamless as possible. + +This can be done iteratively or wholesale to the next size of architecture depending on your circumstances. +For example, if any of your GitLab Rails, Sidekiq, Gitaly, Redis or PostgreSQL nodes are consistently oversaturated, then increase their resources accordingly while leaving the rest of the environment as is. + +If expecting a large increase in users, you may elect to scale up the whole environment to the next +size of architecture. + +If the overall design is being followed, you can scale the environment vertically as required. + +If robust metrics are in place that show the environment is over-provisioned, you can apply the same process for +scaling downwards. You should take an iterative approach when scaling downwards to ensure there are no issues. + +#### Scaling from a non-HA to an HA architecture -In terms of the Reference Architectures, you would look to the next size and adjust accordingly. -Most setups would only need vertical scaling, but there are some specific areas that can be adjusted depending on the setup: +While in most cases vertical scaling is only required to increase an environment's resources, if you are moving to an HA environment, +there may be some additional steps required as shown below: - If you're scaling from a non-HA environment to an HA environment, various components are recommended to be deployed in their HA forms: - - Redis to multi-node Redis w/ Redis Sentinel - - Postgres to multi-node Postgres w/ Consul + PgBouncer - - Gitaly to Gitaly Cluster w/ Praefect + - [Redis to multi-node Redis w/ Redis Sentinel](../redis/replication_and_failover.md#switching-from-an-existing-single-machine-installation) + - [Postgres to multi-node Postgres w/ Consul + PgBouncer](../postgresql/moving.md) + - [Gitaly to Gitaly Cluster w/ Praefect](../gitaly/index.md#migrate-to-gitaly-cluster) - From 10k users and higher, Redis is recommended to be split into multiple HA servers as it's single threaded. Conversely, if you have robust metrics in place that show the environment is over-provisioned, you can apply the same process for