On 18/03/2011 10:35 PM, hostalp@post.cz wrote:
For multithreaded case I slightly modified the test to run with 100 threads, each producing 10000 log events. The profile data shows high lock contention in method ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(java.lang.Object) (same as I mentioned in my previous mail) and thread dumps always reveal one runnable thread doing some writing while all other threads are waiting for it. Run times are typically 2-3 times worse than with log4j with immediateFlush=false (6.3-9s vs. 13-20s). So some sort of write batching/buffering really helps in case of heavy activity.
The last time I checked the performance difference with and without immediate flush the difference was in the order of 10%. It has apparently ballooned to something much more significant. Thank you for bringing this up. -- QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software developers. For further details, see http://logback.qos.ch/job.html