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] > >
