Let me optimize a bit with the ThreadLocal idea before adding it to the performance page.
Sent from my iPhone > On 2016/04/13, at 3:27, Ralph Goers <[email protected]> wrote: > > Something you could add to the performance page on the site perhaps? > > If I am not mistaken Logback still has code that doesn’t use > UnsynchronizedAppenderBase so it would have more locking contention. But I > don’t know if this test is one of them. I would agree that a ThreadLocal > byte buffer might make a difference. > > Ralph > >> On Apr 12, 2016, at 9:30 AM, Remko Popma <[email protected]> wrote: >> >> I wanted to share the results of some initial performance tests. >> >> This is from the log4j-perf FileAppenderBenchmark, starting with 1 thread, >> ending at 64 threads. It compares Logback to Log4j 1.2 to Log4j 2. >> >> Point of interest for me is "direct enc": use the garbage-free >> Layout.encode(LogEvent, ByteBufferDestination), vs. "allocate": create >> byte[] and Strings by calling Layout.toByteArray(). >> >> <FileAppenderLinux2.6.png> >> >> Looks like at the moment garbage-free is better with a single thread and >> allocating is better with more threads. >> >> This is because the current implementation locks on the OutputStreamManager >> while writing into the shared buffer. >> >> I'm very happy with this initial result. >> We can probably improve on this with a threadlocal byte buffer so we only >> need to lock when copying that threadlocal buffer into the shared buffer. >> >> What is also interesting is how much better Log4j 2 is compared to Logback >> and Log4j, especially with more than one thread. >> >> Command to run the tests: >> java -Dlog4j2.enable.direct.encoders=true -jar >> benchmarks-LOG4J2-1343-20160411.jar ".*FileAppender.*" -f 1 -wi 10 -i 20 -bm >> thrpt -tu s -t 1 >> >> (increase threads with -t 2, -t 4 etc, use >> log4j2.enable.direct.encoders=false to use Layout.toByteArray()) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
