OSDOCS-4328: Edits from the Optimizing Routing content audit

Author: ahardin-rh

modules/baseline-router-performance.adoc

@@ -5,7 +5,7 @@
 [id="baseline-router-performance_{context}"]
 = Baseline Ingress Controller (router) performance
 
-The {product-title} Ingress Controller, or router, is the Ingress point for all external traffic destined for {product-title} services.
+The {product-title} Ingress Controller, or router, is the ingress point for ingress traffic for applications and services that are configured using routes and ingresses.
 
 When evaluating a single HAProxy router performance in terms of HTTP requests handled per second, the performance varies depending on many factors. In particular:
 
@@ -47,8 +47,7 @@ In HTTP close (no keep-alive) scenarios:
 |re-encrypt |2320|2941
 |===
 
-Default Ingress Controller configuration with `ROUTER_THREADS=4` was used and two different endpoint publishing strategies (LoadBalancerService/HostNetwork) were tested.
-TLS session resumption was used for encrypted routes. With HTTP keep-alive, a single HAProxy router is capable of saturating 1 Gbit NIC at page sizes as small as 8 kB.
+The default Ingress Controller configuration was used with the `spec.tuningOptions.threadCount` field set to `4`. Two different endpoint publishing strategies were tested: Load Balancer Service and Host Network. TLS session resumption was used for encrypted routes. With HTTP keep-alive, a single HAProxy router is capable of saturating a 1 Gbit NIC at page sizes as small as 8 kB.
 
 When running on bare metal with modern processors, you can expect roughly twice the performance of the public cloud instance above. This overhead is introduced by the virtualization layer in place on public clouds and holds mostly true for private cloud-based virtualization as well. The following table is a guide to how many applications to use behind the router:
 
@@ -60,9 +59,7 @@ When running on bare metal with modern processors, you can expect roughly twice
 
 |===
 
-In general, HAProxy can support routes for 5 to 1000 applications, depending on
-the technology in use. Ingress Controller performance might be limited by the
-capabilities and performance of the applications behind it, such as language or
-static versus dynamic content.
+In general, HAProxy can support routes for up to 1000 applications, depending on the technology in use. Ingress Controller performance might be limited by the
+capabilities and performance of the applications behind it, such as language or static versus dynamic content.
 
 Ingress, or router, sharding should be used to serve more routes towards applications and help horizontally scale the routing tier.

modules/ingress-liveness-readiness-startup-probes.adoc

@@ -7,7 +7,7 @@
 = Configuring Ingress Controller liveness, readiness, and startup probes
 
 Cluster administrators can configure the timeout values for the kubelet's liveness, readiness, and startup probes for router deployments that are managed by the {product-title} Ingress Controller (router). The liveness and readiness probes of the router use the default timeout value
-of 1 second, which is too short for the kubelet's probes to succeed in some scenarios. Probe timeouts can cause unwanted router restarts that interrupt application connections. The ability to set larger timeout values can reduce the risk of unnecessary and unwanted restarts.
+of 1 second, which is too brief when networking or runtime performance is severely degraded. Probe timeouts can cause unwanted router restarts that interrupt application connections. The ability to set larger timeout values can reduce the risk of unnecessary and unwanted restarts.
 
 You can update the `timeoutSeconds` value on the `livenessProbe`, `readinessProbe`, and `startupProbe` parameters of the router container.
 
@@ -19,7 +19,7 @@ You can update the `timeoutSeconds` value on the `livenessProbe`, `readinessProb
  |The `livenessProbe` reports to the kubelet whether a pod is dead and needs to be restarted.
 
  |`readinessProbe`
- |The `readinessProbe` reports whether a pod is healthy or unhealthy. When the readiness probe reports an unhealthy pod, then the kubelet marks the pod as not ready to accept traffic. Subsequently, the endpoints for that pod are marked as not ready, and this status propogates to the kube-proxy. On cloud platforms with a configured load balancer, the kube-proxy communicates to the cloud load-balancer not to send traffic to the node with that pod.
+ |The `readinessProbe` reports whether a pod is healthy or unhealthy. When the readiness probe reports an unhealthy pod, then the kubelet marks the pod as not ready to accept traffic. Subsequently, the endpoints for that pod are marked as not ready, and this status propagates to the kube-proxy. On cloud platforms with a configured load balancer, the kube-proxy communicates to the cloud load-balancer not to send traffic to the node with that pod.
 
  |`startupProbe`
  |The `startupProbe` gives the router pod up to 2 minutes to initialize before the kubelet begins sending the router liveness and readiness probes.  This initialization time can prevent routers with many routes or endpoints from prematurely restarting.

modules/router-performance-optimizations.adoc

@@ -106,13 +106,11 @@ include::modules/ossm-installation-activities.adoc[leveloffset=+2]
 [id="post-installationrouting-optimization"]
 == Optimizing routing
 
-The {product-title} HAProxy router scales to optimize performance.
+The {product-title} HAProxy router can be scaled or configured to optimize performance.
 
 include::modules/baseline-router-performance.adoc[leveloffset=+2]
-
-include::modules/router-performance-optimizations.adoc[leveloffset=+2]
-include::modules/ingress-liveness-readiness-startup-probes.adoc[leveloffset=+3]
-include::modules/configuring-haproxy-interval.adoc[leveloffset=+3]
+include::modules/ingress-liveness-readiness-startup-probes.adoc[leveloffset=+2]
+include::modules/configuring-haproxy-interval.adoc[leveloffset=+2]
 
 [id="post-installation-osp-fips"]
 == Post-installation {rh-openstack} network configuration

post_installation_configuration/network-configuration.adoc

@@ -6,12 +6,13 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The {product-title} HAProxy router scales to optimize performance.
+The {product-title} HAProxy router can be scaled or configured to optimize performance.
 
 include::modules/baseline-router-performance.adoc[leveloffset=+1]
 
 For more information on Ingress sharding, see xref:../networking/ingress-operator.adoc#nw-ingress-sharding-route-labels_configuring-ingress[Configuring Ingress Controller sharding by using route labels] and xref:../networking/ingress-operator.adoc#nw-ingress-sharding-namespace-labels_configuring-ingress[Configuring Ingress Controller sharding by using namespace labels].
 
-include::modules/router-performance-optimizations.adoc[leveloffset=+1]
-include::modules/ingress-liveness-readiness-startup-probes.adoc[leveloffset=+2]
-include::modules/configuring-haproxy-interval.adoc[leveloffset=+2]
+You can modify the Ingress Controller deployment using the information provided in xref:../networking/ingress-operator.adoc#nw-ingress-setting-thread-count[Setting Ingress Controller thread count] for threads and xref:../networking/ingress-operator.adoc#nw-ingress-controller-configuration-parameters_configuring-ingress[Ingress Controller configuration parameters] for timeouts, and other tuning configurations in the Ingress Controller specification.
+
+include::modules/ingress-liveness-readiness-startup-probes.adoc[leveloffset=+1]
+include::modules/configuring-haproxy-interval.adoc[leveloffset=+1]