> If we would move the appender performance aside, am I right to conclude > that the entire complex async. framework built atop Disruptor with all its > whistles and bells is yielding a diminishing performance gain compared to a > simple off the shelf blocking queue?
I haven't seen any data that would give me such an impression -- the file appender itself is slower than the thread producing events, which appears to limit our throughput. Even then, log4j2 does much better in my testing on a linux workstation with 20+ producer threads compared to logback. Any time the queue is constantly full, performance will suffer (and this applies to standard blocking queues as well as disruptor, however disruptor will fare worse when the queue is full). The results using a single thread are roughly reproducible on the non-async test, so I think the problem is somewhere between the layout, and appender/manager. Results running locally with no-op appender implementations: 1 thread: Benchmark Mode Cnt Score Error Units AsyncWithFileAppenderBenchmark.log4j2AsyncFile thrpt 4 3285.743 ± 427.963 ops/ms AsyncWithFileAppenderBenchmark.logbackFile thrpt 4 2383.532 ± 136.034 ops/ms 20 threads: Benchmark Mode Cnt Score Error Units AsyncWithFileAppenderBenchmark.log4j2AsyncFile thrpt 4 1177.746 ± 919.560 ops/ms AsyncWithFileAppenderBenchmark.logbackFile thrpt 4 602.614 ± 47.485 ops/ms
