Span compression

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:

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.

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

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

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

Support for span compression is available in these agents: