Fluent Bit Throughput Calculator

Calculate maximum Fluent Bit throughput from worker count and per-worker throughput, and identify pipeline bottlenecks against required ingestion rate.

Inputs

Worker Threadsworkers

Number of Fluent Bit output worker threads (the `workers` setting on an output plugin).

Per-Worker ThroughputMB/sec

Sustained throughput a single worker can push to the output destination.

Required ThroughputMB/sec

The actual ingestion rate that must be sustained (from your log ingestion sizing).

Max Throughput

32.00MB/sec

Utilization at Required Rate

78.1%

Bottlenecked

false

Min Workers for Required Rate

4workers

Headroom

7.00MB/sec

Step by step

Max throughput: workers × per-worker throughput
4 × 8
= 32.00 MB/sec
Utilization: required ÷ max
25 ÷ 32.00
= 78.1%
Min workers needed for required throughput
ceil(25 ÷ 8)
= 4 workers

How it works

Fluent Bit's maximum sustained throughput scales with the number of output worker threads: max_throughput = workers × per_worker_MBps. Comparing this against your actual required ingestion rate identifies whether the pipeline is bottlenecked — if required throughput exceeds capacity, logs will queue and eventually be dropped or cause backpressure upstream, and more workers (or a faster per-worker configuration) are needed.

Formula

max_throughput_MBps = workers × per_worker_MBps

workers: Number of output worker threads
per_worker_MBps: Sustained throughput per worker (MB/sec)

Frequently Asked Questions

How do I measure per-worker throughput?

Benchmark a single Fluent Bit output worker against your actual destination (e.g. OpenSearch, Kafka, S3) under sustained load — network latency, destination-side indexing speed, and payload size all affect this figure, so generic defaults are only a starting estimate.

Does adding workers always increase throughput linearly?

Only up to a point — beyond a certain worker count, CPU contention, network saturation, or backend-side throttling (e.g. Elasticsearch bulk queue limits) will cap further gains, so linear scaling assumptions should be validated with real load tests.

What should I do if the pipeline is bottlenecked?

Add more output workers, batch/compress payloads more aggressively, scale out to multiple Fluent Bit instances, or address destination-side throughput limits (e.g. more Elasticsearch ingest nodes) — whichever is cheaper for your bottleneck.

Is Fluent Bit throughput different from Fluentd?

Fluent Bit is written in C with a much smaller memory/CPU footprint than Ruby-based Fluentd, so its per-worker throughput is typically several times higher — but the same workers × per-worker-throughput model applies to both.

You might also need

Log Ingestion Calculator Fluentd Buffer Calculator Log Parsing Performance Calculator