Kafka Benchmark: Producer and Consumer Throughput, Replication, Message Size, and Latency Analysis

Test Environment

The benchmark runs on six machines, each with an Intel Xeon 2.5 GHz six‑core CPU, six 7200 RPM SATA drives, 32 GB RAM, and 1 Gb Ethernet. Three machines host a Kafka broker cluster, the other three run Zookeeper and generate test data; all drives are mounted non‑RAID.

Producer Throughput

Only the producer side is measured, persisting data without any consumer reads.

1 producer thread, no replication

A topic with six partitions and no replication is fed by a single thread generating 50 million short (100‑byte) messages, achieving 821,557 records/second (≈78.3 MB/s). Overheads such as keys, CRC, and protocol metadata add ~22 bytes per record, pushing network usage near the 1 Gb Ethernet limit.

Linear disk I/O on six cheap disks yields ~822 MB/s, far exceeding the network ceiling.

Kafka’s batch processing greatly boosts I/O efficiency.

1 producer thread, 3 asynchronous replicas

Same test with three replicas per partition (asynchronous replication) yields 786,980 records/second (≈75.1 MB/s). Asynchronous ack reduces latency, though total data written triples.

1 producer thread, 3 synchronous replicas

With synchronous replication, each record is committed only after all in‑sync replicas acknowledge, resulting in 421,823 records/second (≈40.2 MB/s). No batch‑size tuning was applied to keep results comparable.

3 producers, 3 asynchronous replicas

Running three producers on separate machines (network already saturated) reaches 2,024,032 records/second (≈193 MB/s).

Producer Throughput vs. Stored Data

Kafka’s O(1) disk‑persistence means throughput remains stable regardless of data volume on disk, as shown by a long‑running test where throughput does not degrade even when stored data grows to 1 TB.

Variances stem from Linux I/O caching and batch flushing; the test reflects a tuned production cluster.

Consumer Throughput

Replication factor does not affect consumer throughput because consumers read only from the leader partition.

1 consumer

Consuming 50 million messages from a 6‑partition, 3‑replica topic yields 940,521 records/second (≈89.7 MB/s). Kafka uses the sendfile API to transfer data directly from kernel space, minimizing user‑space copies.

3 consumers

Running three consumers in parallel on separate machines scales almost linearly to 2,615,968 records/second (≈249.5 MB/s).

Combined Producer and Consumer

With one producer and one consumer (asynchronous replication) on a 6‑partition, 3‑replica topic, the combined throughput is 795,064 records/second (≈75.8 MB/s), essentially matching the producer‑only result, indicating the consumer adds negligible load.

Impact of Message Size on Throughput

Short messages (100 bytes) are the hardest case. As payload size increases, records/second drop while MB/second rises, eventually saturating bandwidth. Graphs illustrate the trade‑off.

End‑to‑End Latency

Measuring a single producer‑consumer pair gives a median latency of 2 ms, 99th‑percentile 3 ms, and 99.9th‑percentile 14 ms. Details such as partition count and replication mode are omitted, though they significantly affect latency.

Reproducing the Benchmark

Readers can repeat the tests using Kafka’s built‑in producer performance script: bin/kafka-producer-perf-test.sh Typical command lines (shown as images) configure record size, throughput, and other parameters. Additional tuning tips are referenced in the original report.

Source: Jason's Blog (http://www.jasongj.com/2015/01/02/Kafka深度解析/)