› › ›

处理和性能

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 之外，还可以考虑减少摄取量。在减少存储中了解更多信息。