Hello, yes You're right the test should be reduced, I left those cases there for curiosity to see how much does the isDebugEnabled check and parametrized logging call affect the results. Your test gives somehing like the following: HP-UX: ############################################### Log4j direct debug call: 7166 Logback direct debug call: 12357 ############################################### Windows: ############################################### Log4j direct debug call: 7122 Logback direct debug call: 17015 ############################################### Which is more or less consistent with previous tests with rolling file appender used. What we're dealing with in multithreaded environment after switching to logback is massive lock contention in the ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(java.lang.Object) method (seen in the profile data) and generally worse performance which is the reason why we started with some isolated testing.