In some cases, APM agents may collect large amounts of very similar or identical spans in a transaction. For example, this can happen if spans are captured inside of a loop, or in unoptimized SQL queries that use multiple queries instead of joins to fetch related data. In such cases, the upper limit of spans per transaction (by default, 500 spans) can be reached quickly, causing the agent to stop capturing potentially more relevant spans for a given transaction.

Such repeated similar spans often aren’t very relevant for themselves, especially if they are of very short duration. They also can clutter the UI, and cause processing and storage overhead.

To address this problem, the APM agents can compress such spans into a single span. The compressed span retains most of the original span information, such as overall duration and the number of spans it represents.

Regardless of the compression strategy, a span is eligible for compression if:

Compression strategiesedit

The APM agent can select between two strategies to decide if two adjacent spans can be compressed. Both strategies have the benefit that only one previous span needs to be kept in memory. This is important to ensure that the agent doesn’t require large amounts of memory to enable span compression.

Same-Kind strategyedit

The agent selects this strategy if two adjacent spans have the same:

Exact-Match strategyedit

The agent selects this strategy if two adjacent spans have the same:

Settingsedit

The agent has configuration settings to define upper thresholds in terms of span duration for both strategies. For the "Same-Kind" strategy, the limit is 5 milliseconds. For the "Exact-Match" strategy, the limit is 50 milliseconds. Spans with longer duration are not compressed. Please refer to the agent documentation for specifics.

Agent supportedit

Support for span compression is available in these agents: