› › › ›

处理和性能

APM Server 的性能取决于多种因素：可用的内存和 CPU、网络延迟、事务大小、工作负载模式、代理和服务器设置、版本以及协议。

我们测试了几种场景，以帮助您了解如何调整 APM Server 的大小，使其能够跟上 Elastic APM 代理发送的负载

在 Elastic Cloud 上使用 AWS、GCP 和 Azure 的默认硬件模板。
对于每个硬件模板，测试了几种大小：1 GB、4 GB、8 GB 和 32 GB。
对于每种大小，使用固定数量的 APM 代理：1 GB 为 10 个代理，4 GB 为 30 个代理，8 GB 为 60 个代理，32 GB 为 240 个代理。
在所有场景中，都使用中等大小的事件。事件包括事务和跨度。

您还需要相应地扩展 Elasticsearch，可能需要配置增加的分片数量。有关扩展 Elasticsearch 的更多详细信息，请参阅Elasticsearch 文档。

以下结果包括合成工作负载的数字。您可以使用我们的测试结果来指导您的大小调整决策，但是，性能将因您用例的独特因素而异，例如您的特定设置、APM 事件数据的大小以及代理的确切数量。

配置文件 / 云	AWS	Azure	GCP
1 GB (10 个代理)	9,000 事件/秒	6,000 事件/秒	9,000 事件/秒
4 GB (30 个代理)	25,000 事件/秒	18,000 事件/秒	17,000 事件/秒
8 GB (60 个代理)	40,000 事件/秒	26,000 事件/秒	25,000 事件/秒
16 GB (120 个代理)	72,000 事件/秒	51,000 事件/秒	45,000 事件/秒
32 GB (240 个代理)	135,000 事件/秒	95,000 事件/秒	95,000 事件/秒

不要忘记 APM Server 是无状态的。运行的多个实例不需要彼此了解。这意味着，使用适当大小的 Elasticsearch 实例，APM Server 可以线性扩展。

RUM 值得特别考虑。RUM 代理在浏览器中运行，可能有成千上万的浏览器向具有非常可变的网络延迟的 APM Server 报告。

除了扩展 APM Server 之外，或者作为扩展 APM Server 的补充，请考虑减少摄取量。请在减少存储中阅读更多信息。