address initial feedback

docs/processing-performance.asciidoc

@@ -9,26 +9,23 @@ agent and server settings, versions, and protocol.
 // TBD
 
 // Method
-To help you understand how sizing APM Server impacts performance, we tested several scenarios:
+We tested several scenarios to help you understand how to size the APM Server so that it can keep up with the load that your Elastic APM agents are sending:
 
 * Using the default hardware template on AWS, GCP and Azure on {ecloud}.
-* Comparing the performance when using OpenTelemetry (OTel) events on at least one of the service providers listed above (in this case, GCP).
 * For each hardware template, testing with several sizes: 1 GB, 4 GB, 8 GB, and 32 GB.
 * For each size, using a fixed number of APM agents: 10 agents for 1 GB, 30 agents for 4 GB, 60 agents for 8 GB, and 240 agents for 32 GB.
 * In all scenarios, using medium sized events. Events include
 <<data-model-transactions,transactions>> and
 <<data-model-spans,spans>>.
 
-// This leaves us with relevant variables like payload and instance sizes.
-
 // Results
 You can use the results of our tests to guide your sizing decisions, however, performance will vary based on factors unique to your use case like your specific setup, the size of APM event data, and the exact number of agents.
 
 :hardbreaks-option:
 
 [options="header"]
 |====
-| Profile / Cloud | AWS | Azure | GCP (Agent) | GCP (OTel)
+| Profile / Cloud | AWS | Azure | GCP
 
 | *1 GB*
 (10 agents)
@@ -38,8 +35,6 @@ events/second
 events/second
 | 9,600
 events/second
-| 28,000
-events/second
 
 | *4 GB*
 (30 agents)
@@ -49,9 +44,7 @@ events/second
 events/second
 | 17,800
 events/second
-| 49,300
-events/second
-
+
 | *8 GB*
 (60 agents)
 | 40,500
@@ -60,8 +53,6 @@ events/second
 events/second
 | 25,700
 events/second
-| 89,300
-events/second
 
 | *16 GB*
 (120 agents)
@@ -71,8 +62,6 @@ events/second
 events/second
 | 45,300
 events/second
-| 145,000
-events/second
 
 | *32 GB*
 (240 agents)
@@ -82,33 +71,18 @@ events/second
 events/second
 | 95,000
 events/second
-| 381,000
-events/second
 
 |====
 
 :!hardbreaks-option:
 
-// In other words, a 512 MB instance can process \~3 MB per second,
-// while an 8 GB instance can process ~20 MB per second.
-
 APM Server is CPU bound and larger instance types in {ecloud} come with much more computing power.
-// so it scales better from 2 GB to 8 GB than it does from 512 MB to 2 GB.
 
 Don't forget that the APM Server is stateless.
 Several instances running do not need to know about each other.
 This means that with a properly sized {es} instance, APM Server scales out linearly.
 
 NOTE: RUM deserves special consideration. The RUM agent runs in browsers, and there can be many thousands reporting to an APM Server with very variable network latency.
 
-// [discrete]
-// ==== Troubleshoot sizing issues
-
-// [discrete]
-// ===== Scale the APM Server and ES
-
-// [discrete]
-// ===== Apply head based sampling
-
-// [discrete]
-// ===== Apply tail based sampling
+If your APM Server cannot be scaled to support the load that you are expecting, consider
+decreasing the ingestion volume. Read more in <<reduce-apm-storage>>.