Robin, this is a JMH benchmark. I _think_ it simply counts the number of times the test code (logger.log(...)) was invoked for all threads together. Need to double check.
In which case this would be a good illustration of Amdahl's law. https://en.wikipedia.org/wiki/Amdahl%27s_law (Conclusion: Write single-threaded apps or use the lock free async Loggers. ) Sent from my iPhone > On 2016/04/13, at 5:32, Robin Coe <[email protected]> wrote: > > Is that total msg/s across all threads or per thread? I expect it's per > thread but wanted to be sure, as the single threaded performance would make > it seem that you shouldn't run multithreaded. > >> On Tue, Apr 12, 2016 at 2:27 PM, 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] >
