性能影响和开销

如AWS Lambda 的 APM 架构中所述，使用 Elastic APM 与 AWS Lambda 需要同时添加 Elastic APM AWS Lambda 扩展和相应的 Elastic APM 代理到 Lambda 运行时。这些组件可能会稍微增加函数部署包的大小以及函数调用执行时长。

这些组件会略微增加 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 文档中了解有关相应调整选项的更多信息。