# Batching Configuration Performance Impact

Poor batching placement can lead to:

* Excessive CPU load from per-record processing
* Higher memory pressure from holding unbatched data longer than necessary
* Reduced throughput due to inefficient export batching

Optimal batching strategy is workload-specific. Without careful tuning, performance can drop by thousands of telemetry items per second.

The batch processor groups telemetry signals into batches to reduce per-export overhead.

#### Two main placement strategies

1. **Early Batching** – Batch immediately after the receiver:

```
Receiver → Batch Processor → Other Processors → Exporter
```

* Pros:
  * Downstream processors work with fewer, larger payloads
  * Reduced CPU context switching downstream
* Cons:
  * Batch-wide transformations can be more expensive if data is later dropped
  * Potential for higher memory usage if downstream processors expand batches

2. **Late Batching** – Batch just before export:

```
Receiver → Other Processors → Batch Processor → Exporter
```

* Pros:
  * Processors handle smaller, more granular payloads
  * Reduces wasted processing on items that may be filtered out later
* Cons:
  * Less benefit from batching in earlier stages; higher per-record overhead in processing

#### Observed Performance Differences

From benchmarking across varied workloads:

* **Early batching tends to improve throughput by \~10% in simple pipelines** and reduce CPU usage for high-volume, low-complexity telemetry.
* **Late batching performs better in complex pipelines** with multiple processing stages, avoiding expensive batch-wide operations on data that will be dropped or heavily modified.
* Batch size and timeout settings (`send_batch_max_size`, `timeout`) directly influence both throughput and resource usage.

#### Solution

Choose batching placement based on processing complexity and data volume:

| Workload Type                                    | Recommended Placement | Reason                                              |
| ------------------------------------------------ | --------------------- | --------------------------------------------------- |
| High-volume, low-complexity (minimal processing) | Early Batching        | Minimizes per-record overhead early in the pipeline |
| Complex, multi-processor pipelines               | Late Batching         | Avoids unnecessary batch-wide transformations       |

Early Batching Example:

```yaml
service:
  pipelines:
    logs:
      receivers: [my_receiver]
      processors: [batch, memory_limiter, attributes]
      exporters: [otlphttp]
```

Late Batching Example:

```yaml
service:
  pipelines:
    logs:
      receivers: [my_receiver]
      processors: [memory_limiter, attributes, batch]
      exporters: [otlphttp]
```