- Observability: other versions:
- What is Elastic Observability?
- What’s new in 8.13
- Get started
- Observability AI Assistant
- Application performance monitoring (APM)
- Self manage APM Server
- Data Model
- Features
- How-to guides
- OpenTelemetry integration
- Manage storage
- Configure
- Advanced setup
- Secure communication
- Monitor
- API
- Troubleshoot
- Upgrade
- Release notes
- Known issues
- Log monitoring
- Infrastructure monitoring
- AWS monitoring
- Azure monitoring
- Synthetic monitoring
- Get started
- Scripting browser monitors
- Configure lightweight monitors
- Manage monitors
- Work with params and secrets
- Analyze monitor data
- Monitor resources on private networks
- Use the CLI
- Configure projects
- Configure Synthetics settings
- Grant users access to secured resources
- Manage data retention
- Use Synthetics with traffic filters
- Migrate from the Elastic Synthetics integration
- Scale and architect a deployment
- Synthetics support matrix
- Synthetics Encryption and Security
- Troubleshooting
- Uptime monitoring
- Real user monitoring
- Universal Profiling
- Alerting
- Service-level objectives (SLOs)
- Cases
- CI/CD observability
- Troubleshooting
- Fields reference
- Tutorials
Processing and performance
editProcessing and performance
editAPM Server performance depends on a number of factors: memory and CPU available, network latency, transaction sizes, workload patterns, agent and server settings, versions, and protocol.
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 Elastic Cloud.
- 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 transactions and spans.
You will also need to scale up Elasticsearch accordingly, potentially with an increased number of shards configured. For more details on scaling Elasticsearch, refer to the Elasticsearch documentation.
The results below include numbers for a synthetic workload. 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.
| Profile / Cloud | AWS | Azure | GCP |
|---|---|---|---|
1 GB |
9,000 |
6,000 |
9,000 |
4 GB |
25,000 |
18,000 |
17,000 |
8 GB |
40,000 |
26,000 |
25,000 |
16 GB |
72,000 |
51,000 |
45,000 |
32 GB |
135,000 |
95,000 |
95,000 |
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 Elasticsearch instance, APM Server scales out linearly.
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.
Alternatively or in addition to scaling the APM Server, consider decreasing the ingestion volume. Read more in Reduce storage.