性能影响和开销

如 AWS Lambda 的 APM 架构 中所述，在 AWS Lambda 中使用 Elastic APM 需要在 Lambda 运行时添加 Elastic APM AWS Lambda 扩展和相应的 Elastic APM 代理。这些组件可能会对函数部署包的大小以及函数调用执行持续时间造成轻微的开销。

对部署包大小的影响编辑

这些组件会对 Lambda 函数的未压缩部署包大小造成轻微的影响。总体而言，使用 Elastic APM 对 Lambda 函数的未压缩部署包大小的影响小于 30MB。

性能影响编辑

Elastic APM AWS Lambda 扩展架构的一个优势是，APM 数据分发与函数的请求处理分离。Elastic APM AWS Lambda 扩展在函数响应客户端请求之后将 APM 数据刷新到 Elastic 后端。因此，它不会影响客户端请求的延迟。但是，扩展刷新 APM 数据会增加函数调用的总执行时间。 ELASTIC_APM_DATA_FORWARDER_TIMEOUT 配置选项以及相关的指数回退算法限制并允许控制扩展对函数总执行时间的影响。

当函数遇到冷启动时，Elastic APM AWS Lambda 扩展需要进行初始化，因此会略微增加函数的冷启动持续时间（在几十毫秒范围内）。

APM 代理使用测量代码来丰富应用程序的代码，以收集 APM 数据。此测量代码会对应用程序造成轻微的性能开销，通常在可以忽略不计的范围内。Lambda 函数也是如此。APM 代理造成的具体性能开销高度依赖于代理的配置以及函数代码的特性。以下代理特定文档页面提供有关调整 APM 代理性能的见解和说明

与 Elastic APM AWS Lambda 扩展类似，APM 代理在冷启动时进行初始化。因此，与热调用相比，APM 代理在冷启动时的开销会更高。这种影响对 AWS Lambda 上的 Java APM 代理尤其明显。在 Java 代理的 AWS Lambda 文档 中了解有关相应调整选项的更多信息。