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]
