性能调优
编辑性能调优编辑
使用 APM 解决方案需要权衡利弊,Elastic APM 的 Python 代理也不例外。检测代码、测量时间、记录上下文数据等都需要资源
- CPU 时间
- 内存
- 带宽使用
- Elasticsearch 存储
我们投入并持续投入大量精力来尽可能降低使用 Elastic APM 的开销。但由于每个部署都不同,您可以调整一些旋钮以使其适应您的特定需求。
事务采样率编辑
降低代理开销的最简单方法是告诉代理减少工作量。如果将 transaction_sample_rate
设置为小于 1.0
的值,则代理将随机采样一部分事务。未采样的事务仅记录事务的名称、总事务时间和结果
字段 | 已采样 | 未采样 |
---|---|---|
事务名称 |
是 |
是 |
持续时间 |
是 |
是 |
结果 |
是 |
是 |
上下文 |
是 |
否 |
标签 |
是 |
否 |
跨度 |
是 |
否 |
将采样率降低到所有事务的一小部分可以显着减少上述四种资源类型的使用量。
事务队列编辑
为了减少 APM 服务器的负载,代理不会在每个事务发生时立即将其发送出去。相反,它会将它们排队,并定期或在达到最大大小时使用后台线程刷新队列。
虽然这减少了 APM 服务器(以及在一定程度上减少了代理)的负载,但在队列中保存事务数据会占用内存。如果您注意到使用 Python 代理会导致内存使用量大幅增加,则可以使用以下设置
-
api_request_time
以减少队列刷新之间的时间 -
api_request_size
以减少队列的最大大小
第一个设置 api_request_time
在持续存在大量事务时很有用。第二个设置 api_request_size
可以在您遇到事务峰值(短时间内大量事务)时提供帮助。
请记住,减少任一设置的值都会导致代理向 APM 服务器发送更多 HTTP 请求,从而可能导致更高的负载。
每个事务的跨度数编辑
每个事务的平均跨度数会影响代理在每个事务中收集每个跨度的上下文数据所花费的时间,以及 Elasticsearch 中所需的存储空间。根据我们的经验,大多数*常见*事务的跨度数应远低于 100。但是,在某些情况下,跨度数可能会激增
- 长时间运行的事务
- 未优化的代码,例如在循环中执行数百次 SQL 查询
为了避免这些边缘情况使代理和 APM 服务器过载,代理会在达到指定限制时停止记录跨度。您可以通过更改 transaction_max_spans
设置来配置此限制。
跨度堆栈跟踪收集编辑
从性能角度来看,收集跨度的堆栈跟踪的成本可能相当高。堆栈跟踪对于确定代码的哪一部分正在生成跨度非常有用;但是,对于非常短的跨度,这些堆栈跟踪的用处不大(因为有问题的跨度往往更长)。
您可以使用 span_stack_trace_min_duration
设置定义跨度持续时间的最小阈值。如果跨度的持续时间小于此配置值,则不会为此跨度收集堆栈帧。
收集帧上下文编辑
捕获堆栈跟踪时,代理还会捕获堆栈跟踪中每个帧位置周围的几行源代码。这允许 APM 应用程序更深入地了解错误或跨度发生的确切位置。
您可以修改四个设置来控制此行为
如您所见,这些设置分为应用程序帧(代表您的应用程序代码)和库帧(代表您的依赖项的代码)。这些类别中的每一个都进一步分为单独的错误和跨度设置。
在运行的应用程序中读取源文件会导致大量磁盘 I/O,并且为每个帧发送源代码行会产生相当高的网络和存储成本。调低这些限制将有助于防止过度使用内存。
收集标头和请求正文编辑
您可以将 Elastic APM 代理配置为捕获请求和响应的标头 (capture_headers
) 以及请求正文 (capture_body
)。默认情况下,禁用捕获请求正文。为事务启用它可能会导致明显的开销以及存储使用量的增加,具体取决于 POST 请求的性质。在大多数情况下,我们建议不要为事务启用请求正文捕获,并且仅在错误需要时才启用它。
捕获请求/响应标头对代理的开销较小,但可能会影响存储使用量。如果存储使用量对您来说是一个问题,则可能值得禁用它。