处理和性能

编辑

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

我们测试了几个场景,以帮助您了解如何调整 APM 服务器的大小,以便它能够跟上 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 服务器是无状态的。多个正在运行的实例不需要彼此了解。这意味着,使用适当大小的 Elasticsearch 实例,APM 服务器可以线性扩展。

RUM 需要特别考虑。RUM 代理在浏览器中运行,并且可能有数千个代理向 APM 服务器报告,并且网络延迟变化很大。

或者除了扩展 APM 服务器之外,还可以考虑减少摄取量。在减少存储中了解更多信息。