On 18/03/2011 10:35 PM, [email protected] 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
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
