I’m wondering if you could do me a favor. I am color blind and have a hard time differentiating which graph is which. Can you also incorporate dots or dashes into the lines so I can tell the difference?
Ralph > On Apr 13, 2016, at 8:31 AM, Remko Popma <[email protected]> wrote: > > On Linux 2.6, using a thread-local buffer (with a final synchronized copy) is > slightly better than doing all of the encoding in a synchronized block, but > the opposite is true on Win 7. Also, the non-garbage free String.getBytes() > mechanism had higher throughput in my multithreaded tests. > > More data is in the attached spreadsheet. > > I will work on a response time (latency) test next. > > <SyncThroughputLinux2.6.png> > <SyncThroughputWin7.png> > > > On Wed, Apr 13, 2016 at 7:59 AM, Remko Popma <[email protected] > <mailto:[email protected]>> wrote: > 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] > > <mailto:[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] > >> <mailto:[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] > > <mailto:[email protected]> > > For additional commands, e-mail: [email protected] > > <mailto:[email protected]> > > > > <FileAppender20160413.xlsx> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]>
