Remove confusing Puma worker guidance

Omnibus now calculates Puma worker count based on available CPU and
Memory. As such, for most users they no longer need to adjust these
settings in installs.

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):