性能调优

使用 APM 解决方案会带来一定的权衡，Elastic APM 的 Python 代理也不例外。检测代码、测量时间、记录上下文数据等都需要资源。

我们投入并持续投入大量精力，以尽可能降低使用 Elastic APM 的开销。但由于每个部署环境都不同，您可以调整一些参数以适应您的特定需求。

降低代理开销最简单的方法是让代理执行更少的任务。如果将transaction_sample_rate设置为低于1.0的值，代理将随机采样一部分事务。未采样的事务仅记录事务名称、整体事务时间和结果。

将采样率降低到所有事务的一小部分，可以显著减少上述四种资源类型的消耗。

为了减轻 APM 服务器的负载，代理不会在事务发生时立即将其发送。而是将其放入队列中，并定期或在达到最大大小时使用后台线程刷新队列。

虽然这减少了 APM 服务器（以及在一定程度上代理）的负载，但在队列中保留事务数据会消耗内存。如果您发现使用 Python 代理会导致内存使用量大幅增加，可以使用以下设置：

第一个设置 api_request_time 适用于事务数量持续较高的场景。第二个设置 api_request_size 适用于事务出现峰值（短时间内大量事务）的场景。

请记住，减小任一设置的值都会导致代理向 APM 服务器发送更多 HTTP 请求，可能导致更高的负载。

每个事务的平均跨度数量会影响代理在每个事务中收集每个跨度上下文数据所需的时间，以及 Elasticsearch 中所需的存储空间。根据我们的经验，大多数*常见*事务的跨度数量应该远低于 100 个。但在某些情况下，跨度数量可能会激增：

为了避免这些极端情况超载代理和 APM 服务器，代理在达到指定限制时停止记录跨度。您可以通过更改 transaction_max_spans 设置来配置此限制。

从性能角度来看，收集跨度的堆栈跟踪成本相当高。堆栈跟踪对于精确定位产生跨度的代码部分非常有用；但是，对于非常短的跨度，这些堆栈跟踪的用处较小（因为有问题的跨度往往较长）。

您可以使用 span_stack_trace_min_duration 设置定义跨度持续时间的最小阈值。如果跨度的持续时间小于此配置值，则不会为此跨度收集堆栈帧。

捕获堆栈跟踪时，代理还会捕获堆栈跟踪中每个帧位置周围的几行源代码。这允许 APM 应用程序更深入地了解错误或跨度发生的确切位置。

您可以修改四个设置来控制此行为：

如您所见，这些设置分为应用程序框架（代表您的应用程序代码）和库框架（代表您的依赖项的代码）。这些类别中的每一个还细分为单独的错误和跨度设置。

在正在运行的应用程序中读取源文件可能会导致大量的磁盘 I/O，并且为每个帧发送源代码行将产生相当高的网络和存储成本。降低这些限制将有助于防止过度使用内存。

您可以配置 Elastic APM 代理来捕获请求和响应的标头 (capture_headers)，以及请求正文 (capture_body)。默认情况下，捕获请求正文是禁用的。为事务启用它可能会带来明显的开销，并增加存储使用量，具体取决于 POST 请求的性质。在大多数情况下，我们建议不要为事务启用请求正文捕获，仅在错误情况下需要时才启用它。

捕获请求/响应标头对代理的开销较小，但会影响存储使用量。如果存储使用量成为问题，则可能值得禁用它。