Merge branch 'puma-ref-arch' into 'master'

Remove Puma worker guidance

See merge request gitlab-org/gitlab!50074

doc/administration/reference_architectures/10k_users.md

@@ -1763,12 +1763,6 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
 
 This section describes how to configure the GitLab application (Rails) component.
 
-In our architecture, we run each GitLab Rails node using the Puma webserver, and
-have its number of workers set to 90% of available CPUs, with four threads. For
-nodes running Rails with other components, the worker value should be reduced
-accordingly. We've determined that a worker value of 50% achieves a good balance,
-but this is dependent on workload.
-
 The following IPs will be used as an example:
 
 - `10.6.0.111`: GitLab application 1

doc/administration/reference_architectures/25k_users.md

@@ -1763,12 +1763,6 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
 
 This section describes how to configure the GitLab application (Rails) component.
 
-In our architecture, we run each GitLab Rails node using the Puma webserver, and
-have its number of workers set to 90% of available CPUs, with four threads. For
-nodes running Rails with other components, the worker value should be reduced
-accordingly. We've determined that a worker value of 50% achieves a good balance,
-but this is dependent on workload.
-
 The following IPs will be used as an example:
 
 - `10.6.0.111`: GitLab application 1

doc/administration/reference_architectures/3k_users.md

@@ -1479,12 +1479,6 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
 
 This section describes how to configure the GitLab application (Rails) component.
 
-In our architecture, we run each GitLab Rails node using the Puma webserver, and
-have its number of workers set to 90% of available CPUs, with four threads. For
-nodes running Rails with other components, the worker value should be reduced
-accordingly. We've determined that a worker value of 50% achieves a good balance,
-but this is dependent on workload.
-
 On each node perform the following:
 
 1. If you're [using NFS](#configure-nfs-optional):

doc/administration/reference_architectures/50k_users.md

@@ -1763,12 +1763,6 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
 
 This section describes how to configure the GitLab application (Rails) component.
 
-In our architecture, we run each GitLab Rails node using the Puma webserver, and
-have its number of workers set to 90% of available CPUs, with four threads. For
-nodes running Rails with other components, the worker value should be reduced
-accordingly. We've determined that a worker value of 50% achieves a good balance,
-but this is dependent on workload.
-
 The following IPs will be used as an example:
 
 - `10.6.0.111`: GitLab application 1

doc/administration/reference_architectures/5k_users.md

@@ -1479,12 +1479,6 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
 
 This section describes how to configure the GitLab application (Rails) component.
 
-In our architecture, we run each GitLab Rails node using the Puma webserver, and
-have its number of workers set to 90% of available CPUs, with four threads. For
-nodes running Rails with other components, the worker value should be reduced
-accordingly. We've determined that a worker value of 50% achieves a good balance,
-but this is dependent on workload.
-
 On each node perform the following:
 
 1. If you're [using NFS](#configure-nfs-optional):