Based on the docs in the JMH samples throughput is the total for all threads. ( http://hg.openjdk.java.net/code-tools/jmh/file/39ed8b3c11ce/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_02_BenchmarkModes.java )
On Wednesday, 13 April 2016, Remko Popma <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> For additional commands, e-mail: [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> >> >
