Fluent Bit Throughput Calculator

Estimate the log throughput Fluent Bit can process given CPU and memory allocation.

About Fluent Bit Throughput Calculator

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)

Worked example

With the default values below, Fluent Bit Throughput Calculator returns Max Throughput of 32.00. Change any input above and every figure here is recalculated in your browser.

Inputs used

Worker Threadsaccepts 1–256 workers: 4 workers
Per-Worker Throughputaccepts 0.1–10,000 MB/sec: 8 MB/sec
Required Throughputaccepts 0–100,000 MB/sec: 25 MB/sec

Results

Max Throughput: 32.00 MB/sec
Utilization at Required Rate: 78.1%
Bottlenecked: false
Min Workers for Required Rate: 4 workers
Headroom: 7.00 MB/sec

Step by step

1Max throughput: workers × per-worker throughput= 32.00 MB/sec
2Utilization: required ÷ max= 78.1%
3Min workers needed for required throughput= 4 workers

Assumptions and limits

The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.