Why Log4j2 Beats Logback: Real‑World Performance Test and Disruptor Secrets

1. Logback vs Log4j2 Performance Test

Benchmark results for Logback (50 threads, 5 000 000 messages) show execution times ranging from 25 373 ms to 27 056 ms. Increasing the thread count to 100 on a 32‑core machine raises the time to 33 376 ms, indicating diminishing returns with higher concurrency.

logback:messageSize = 5000000, threadSize = 50, costTime = 27383ms
logback:messageSize = 5000000, threadSize = 50, costTime = 26391ms
logback:messageSize = 5000000, threadSize = 50, costTime = 25373ms
logback:messageSize = 5000000, threadSize = 50, costTime = 25636ms
logback:messageSize = 5000000, threadSize = 50, costTime = 25525ms
logback:messageSize = 5000000, threadSize = 50, costTime = 25775ms
logback:messageSize = 5000000, threadSize = 50, costTime = 27056ms
logback:messageSize = 5000000, threadSize = 100, costTime = 33376ms

Log4j2 measurements (median values) demonstrate significantly lower latency: on a development machine 15 509 ms, on a high‑end machine 5 042 ms, and on a server 3 832 ms for the same workload.

log4j2:messageSize = 5000000, threadSize = 100, costTime = 15509ms   ---dev
log4j2:messageSize = 5000000, threadSize = 100, costTime = 5042ms    ---high‑end
log4j2:messageSize = 5000000, threadSize = 100, costTime = 3832ms    ---server

The results align with the official Log4j2 data, confirming that asynchronous logging can dramatically increase I/O throughput.

Additional charts compare synchronous, asynchronous, and async‑only appenders, as well as other logging frameworks, highlighting the superior throughput of async loggers.

2. Test Configuration

Log4j2 can be up to ten times faster than Logback under high thread counts, writing roughly 5 million entries (≈0.25 GB) in about three seconds.

For maximum performance, enable asynchronous logging for all loggers. Mixing sync and async reduces the benefit.

Key configuration parameters of the RollingRandomAccessFile appender are shown below; most defaults are sufficient unless logging I/O impacts the main thread.

In the asyncRoot element, setting includeLocation="true" adds class and line information but incurs a small performance penalty.

3. Disruptor Queue

Log4j2’s asynchronous loggers rely on the high‑performance Disruptor library, which replaces traditional locking queues.

Typical async appenders use a BlockingQueue (often an ArrayBlockingQueue) that locks on each operation, leading to cache misses and higher latency.

Disruptor employs a lock‑free ring buffer with CAS operations, eliminating the need for extra indexes and allowing most data to stay in the CPU’s L1 cache.

Source code snippets illustrate the internal queue implementations for both the standard async appender (using ArrayBlockingQueue) and the global async logger (using Disruptor).

Understanding these mechanisms helps developers choose the right logging strategy to avoid bottlenecks in high‑throughput systems.