This all sounds really good! Yes, the filter comparison isn’t as clear as it should be. Yes, it is how long it takes to deny the events in nanoseconds. The results were generated by the FilterPerformanceComparison test class. At the time I tested with 2 Filters - a Marker filter and the MDC filter. If you look at BasicMarker in SLF4J you will notice that the hasReferences method is synchronized. In multi-threaded cases this can cause huge performance issues if you have a Marker with references to other markers (I personally experienced this). Also, the referenceList is a Vector, so the contains methods can throw ConcurrentModificationExceptions if Markers are modified during execution, even though the add and remove methods are synchronized the contains method is not.
The test is currently set up to compare the MDC/ThreadContext Filters during the build. However, I am not sure it is correct. I don’t actually see it setting the value in the thread context, so it wouldn’t be denying the events. Ralph > On May 1, 2016, at 12:44 AM, Remko Popma <remko.po...@gmail.com> wrote: > > I've started to work on this. > > Question: > the current page has a section comparing the performance Log4j 2 Filters to > Logback Filters. Can you point me to the test that generated these results? > What is being tested? I am guessing this is how long it takes to call > logger.log(level, msg) when the filter DENIES the event, is this correct? Is > the unit for the result numbers nanosecond/operation? > > I'm thinking to convert the above filter test to a JMH benchmark. This would > allow people to quickly verify the results on their own machine. > > I need to think a bit on the items to put on the performance page (and to > create benchmarks for). > > * One theme will be a comparison of Log4j 2 to other logging libraries like > Logback/Log4j1/JUL. One thing to measure is synchronized logging throughput. > I'll use this chart > <https://issues.apache.org/jira/browse/LOG4J2-1297?focusedCommentId=15256490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15256490> > for the performance page and use a simpler graph on the garbage-free manual > page. > * Comparing File/RandomAccessFile/MemoryMappedFile appenders > * Documenting the performance of TCP/UDP appenders > * Compare parameterized logging to string concatenation > * Perhaps investigate/document the overhead of using the adapter/bridge > modules (Log4j1-api, commons-logging, slf4j, JUL adapter)? > * Lock-free async logging versus blocking async logging (just a paragraph > with link to the async logging manual page) > * Any Layouts to compare? > > I plan to do most of the performance testing with JMH. The response time test > I'm using to test garbage-free latency gives a more nuanced picture but is > more work to execute, gather results, analyse etc. > > I'll flesh this out more over the coming week. Feedback welcome as always. > > Remko > > > On Wed, Apr 27, 2016 at 10:09 AM, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > Either in the manual or a link above it > > Sent from my iPhone > > On Apr 26, 2016, at 4:41 PM, Remko Popma <remko.po...@gmail.com > <mailto:remko.po...@gmail.com>> wrote: > >> Will do. Was on my TODO-eventually list but I'll move it up. :-) >> Shall we included it in the manual then? >> >> On Wed, Apr 27, 2016 at 6:23 AM, Ralph Goers <ralph.go...@dslextreme.com >> <mailto:ralph.go...@dslextreme.com>> wrote: >> Remko, >> >> The performance page hasn’t been updated in quite some time. It really >> could use some of your nice graphs. Also, it isn’t linked from the main >> menu. The only way I know of to find it is by clicking a link embedded in >> the About page. Do you think you could enhance that page? It would be >> great to see a variation of the chart you made for garbage free logging, >> although I am just thinking of a few charts comparing Log4j 1, Log4j 2, >> Logback and JUL in various scenarios. Something similar to >> https://www.loggly.com/blog/benchmarking-java-logging-frameworks/ >> <https://www.loggly.com/blog/benchmarking-java-logging-frameworks/> would be >> nice, but with similar configurations instead of relying on defaults. >> >> I am still aware that we may need to make improvements to the >> SocketAppender. I still intend to create a version that uses Netty, >> >> Ralph >> >
