Sure. By the way, the previous email had an attachment with the spreadsheet containing the graphs. Can you see if you can open that?
I can see what I can do but it'll take a day. Sent from my iPhone > On 2016/04/14, at 3:31, Ralph Goers <[email protected]> wrote: > > 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]> 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]> 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] >>> > >> >> <FileAppender20160413.xlsx> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >
