Improve performance documentation (#10555)

* Improve performance documentation

Fixes https://github.com/istio/istio/issues/31680

* Apply suggestions from code review

Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

content/en/docs/ops/deployment/performance-and-scalability/index.md

@@ -83,13 +83,12 @@ The latency, throughput, and the proxies' CPU and memory consumption are measure
 ### CPU and memory
 
 Since the sidecar proxy performs additional work on the data path, it consumes CPU
-and memory. As of Istio 1.7, a proxy consumes about 0.5 vCPU per 1000
+and memory. In Istio {{< istio_release_name >}}, a proxy consumes about 0.5 vCPU per 1000
 requests per second.
 
 The memory consumption of the proxy depends on the total configuration state the proxy holds.
 A large number of listeners, clusters, and routes can increase memory usage.
-Istio 1.1 introduced namespace isolation to limit the scope of the configuration sent
-to a proxy. In a large namespace, the proxy consumes approximately 50 MB of memory.
+In a large namespace with [namespace isolation](/docs/reference/config/networking/sidecar/) enabled, the proxy consumes approximately 50 MB of memory.
 
 Since the proxy normally doesn't buffer the data passing through,
 request rate doesn't affect the memory consumption.
@@ -97,8 +96,8 @@ request rate doesn't affect the memory consumption.
 ### Latency
 
 Since Istio injects a sidecar proxy on the data path, latency is an important
-consideration. Istio adds an authentication filter and a telemetry filter and a metadata exchange filter
-to the proxy. Every additional filter adds to the path length inside the proxy and affects latency.
+consideration.
+Every feature Istio adds also adds to the path length inside the proxy and potentially affects latency.
 
 The Envoy proxy collects raw telemetry data after a response is sent to the
 client. The time spent collecting raw telemetry for a request does not contribute
@@ -107,46 +106,30 @@ is busy handling the request, the worker won't start handling the next request
 immediately. This process adds to the queue wait time of the next request and affects
 average and tail latencies. The actual tail latency depends on the traffic pattern.
 
-Note: in Istio release 1.7, we are introducing a new way of measuring performance by enabling `jitter` in
-the load generator. It helps by modeling random traffic from the client side when using connection pools. In the next
-section, we will present both `jitter` and `non-jitter` performance measurements.
-
 ### Latency for Istio {{< istio_release_name >}}
 
 Inside the mesh, a request traverses the client-side proxy and then the server-side
 proxy. In the default configuration of Istio {{< istio_release_name >}} (i.e. Istio with telemetry v2),
-the two proxies add about 2.65 ms and 2.91 ms to the 90th and 99th percentile latency, respectively, over the baseline data plane latency.
-After enabling `jitter`, those numbers reduced to 1.7 ms and 2.69 ms, respectively. We obtained these results using the [Istio benchmarks](https://github.com/istio/tools/tree/{{< source_branch_name >}}/perf/benchmark)
+the two proxies add about 1.7 ms and 2.7 ms to the 90th and 99th percentile latency, respectively, over the baseline data plane latency.
+We obtained these results using the [Istio benchmarks](https://github.com/istio/tools/tree/{{< source_branch_name >}}/perf/benchmark)
 for the `http/1.1` protocol, with a 1 kB payload at 1000 requests per second using 16 client connections, 2 proxy workers and mutual TLS enabled.
 
-{{< image width="90%"
-    link="latency_p90_fortio_without_jitter.svg"
-    alt="P90 latency vs client connections"
-    caption="P90 latency vs client connections without jitter"
->}}
-
-{{< image width="90%"
-    link="latency_p99_fortio_without_jitter.svg"
-    alt="P99 latency vs client connections"
-    caption="P99 latency vs client connections without jitter"
->}}
-
 {{< image width="90%"
     link="latency_p90_fortio_with_jitter.svg"
     alt="P90 latency vs client connections"
-    caption="P90 latency vs client connections with jitter"
+    caption="P90 latency vs client connections"
 >}}
 
 {{< image width="90%"
     link="latency_p99_fortio_with_jitter.svg"
     alt="P99 latency vs client connections"
-    caption="P99 latency vs client connections with jitter"
+    caption="P99 latency vs client connections"
 >}}
 
 - `baseline` Client pod directly calls the server pod, no sidecars are present.
 - `none_both` Istio proxy with no Istio specific filters configured.
 - `v2-stats-wasm_both` Client and server sidecars are present with telemetry v2 `v8` configured.
-- `v2-stats-nullvm_both` Client and server sidecars are present with telemetry v2 `nullvm` configured by default.
+- `v2-stats-nullvm_both` Client and server sidecars are present with telemetry v2 `nullvm` configured by default. This is the default Istio configuration.
 - `v2-sd-full-nullvm_both` Export Stackdriver metrics, access logs and edges with telemetry v2 `nullvm` configured.
 - `v2-sd-nologging-nullvm_both` Same as above, but does not export access logs.
 
@@ -155,5 +138,5 @@ for the `http/1.1` protocol, with a 1 kB payload at 1000 requests per second usi
 Istio uses the following tools for benchmarking
 
 - [`fortio.org`](https://fortio.org/) - a constant throughput load testing tool.
-- [`blueperf`](https://github.com/blueperf/) - a realistic cloud native application.
+- [`nighthawk`](https://github.com/envoyproxy/nighthawk) - a load testing tool based on Envoy.
 - [`isotope`](https://github.com/istio/tools/tree/{{< source_branch_name >}}/isotope) - a synthetic application with configurable topology.