SimpleSpanProcessor or BatchSpanProcessor: trading request-thread latency for telemetry loss under concurrent load

Direct answer

Neither processor is universally better. SimpleSpanProcessor adds export time directly to the request thread, so latency rises with exporter and network cost. BatchSpanProcessor keeps the request path fast until its bounded queue fills, then silently drops spans. Under sustained concurrency, the dominant cost depends on whether your exporter can drain the queue faster than spans arrive; if not, queue saturation and telemetry loss dominate.

Confirmed behavior vs. environment-dependent risk

Confirmed: SimpleSpanProcessor exports synchronously on the thread that ends the span. BatchSpanProcessor queues spans and exports on a background thread. Both preserve trace context; the difference is scheduling.

Environment-dependent: Whether synchronous export adds measurable request latency depends on export duration (serialization, network, collector response time). Whether BatchSpanProcessor drops spans depends on queue size, batch size, export throughput, and arrival rate.

Language-specific defaults

Defaults differ across SDKs. The following values reflect common defaults reported in SDK documentation as of recent releases; verify them against your exact SDK version before relying on them.

SDK	Queue size	Batch size	Schedule delay	Drop policy
Java	2048	512	5000 ms	Drop oldest
Go	8192	512	5 s	Drop newest
.NET	1000	500	5000 ms	Drop oldest
Python	2048	512	5000 ms	Drop oldest

These defaults mean that a short burst of high concurrency can exhaust a .NET queue quickly, while Go's larger queue absorbs more before dropping. The drop policy also differs: Go discards the newest span on overflow, preserving older context, whereas Java, .NET, and Python discard the oldest.

Middle-ground options without SDK changes

1. Increase the queue size and batch size on BatchSpanProcessor to raise the saturation point. This trades memory for retention. Monitor heap or RSS because a large queue under bursty traffic can cause memory pressure.
2. Enable blocking on queue full where the SDK exposes it. This preserves telemetry but reintroduces request-thread latency during saturation, effectively converging toward SimpleSpanProcessor behavior under load. Availability varies by language.
3. Scale the downstream collector or exporter throughput rather than changing the processor. If the background thread cannot drain the queue because the collector is slow, increasing queue size only delays the drop.
4. Use multiple processors if you need different guarantees per exporter. For example, attach a BatchSpanProcessor for high-volume traces and a SimpleSpanProcessor only for a low-rate critical exporter. Be aware that the SimpleSpanProcessor path still blocks the request thread.

There is no documented adaptive processor that automatically switches between blocking and dropping based on load. The SDK requires an explicit choice or a tuned compromise.

Verification steps

1. Enable SDK metrics for queue depth and dropped spans. In Java, this is exposed via the SDK's autoconfigure module; in Go, via the controller; in .NET and Python, via the corresponding metrics listeners.
2. Run a load test with a steady concurrent request rate. Record p50 and p99 request latency from the load generator.
3. Repeat with SimpleSpanProcessor and then BatchSpanProcessor using defaults. Compare request latency and dropped-span counts.
4. Increase load until queue depth approaches the configured maximum. Confirm whether dropped spans rise while request latency stays flat (drop-dominant regime) or whether latency rises first (export-dominant regime).
5. Retest with a larger queue or blocking-on-overflow to confirm the expected shift.

One missing detail

Which language SDK and version are you using? The defaults, the availability of blocking-on-overflow, and the metric names differ enough that the recommendation changes materially.