Not the whole site. The source and download links will point to a snapshot. However, we can update individual pages.
Ralph > On May 7, 2016, at 8:06 PM, Remko Popma <remko.po...@gmail.com> wrote: > > You're asking if it's possible to change the site without doing a release. > I'm not sure, maybe Ralph knows. > > Sent from my iPhone > >> On 2016/05/08, at 11:01, Matt Sicker <boa...@gmail.com> wrote: >> >> For the "nice to have" items, can we rebuild the site after 2.6 and just >> commit that to svn? Or do site releases always need to match up with the >> artifacts? >> >>> On 7 May 2016 at 19:32, Remko Popma <remko.po...@gmail.com> wrote: >>> Understood about Rewrite. >>> >>> I figured that the performance page is the last remaining thing for the 2.6 >>> release. >>> >>> I had a week off from work and made reasonable progress but it is >>> surprisingly time consuming to create the data and then analyze it and do a >>> write up. >>> >>> Still to do "must have": >>> - JMH benchmarks for comparing performance of log4j2's Filter to Logback's >>> TurboFilters >>> - rewrite Async Logger latency section >>> - Log4j2: compare File, RandomAccessFile, MemoryMappedFile, Console and >>> Rewrite appenders (remove RandomAccessFile stuff from Async Logger page) >>> >>> "Nice to have": >>> - Compare socket/syslog appenders between logging libraries >>> - log4j2: Cost of various APIs/wrappers (SLF4J, Log4j1, JUL, Commons >>> Logging) >>> - log4j2: Compare performance all layouts (CSV, Gelf, HTML, JSON, Pattern, >>> RFC-5424, Serialized, Syslog, XML). >>> >>> The full todo list is here: >>> https://issues.apache.org/jira/browse/LOG4J2-1179 >>> >>> Please do "mvn site", take a look at the current state of the Performance >>> page and let me know if you find any issues. >>> >>> I might postpone some or all of the "nice to have" items to later, unless >>> someone disagrees. >>> >>> Sent from my iPhone >>> >>>> On 2016/05/08, at 4:02, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>>> >>>> No, I have nothing particular in mind for that. >>>> >>>> Just to let you know - and not to put any pressure on - I am waiting for >>>> this page before we do a release. I think it is pretty important, >>>> especially with the detailed results you are producing. >>>> >>>> Ralph >>>> >>>>> On May 7, 2016, at 9:33 AM, Remko Popma <remko.po...@gmail.com> wrote: >>>>> >>>>> Ralph, >>>>> >>>>> Started to work on a benchmark to compare Log4j2's File, >>>>> RandomAccessFile, MemoryMappedFile, Console and Rewrite appenders. >>>>> Is there any particular scenario you want to test with Rewrite appenders? >>>>> >>>>> Remko >>>>> >>>>>> On Mon, May 2, 2016 at 11:51 PM, Remko Popma <remko.po...@gmail.com> >>>>>> wrote: >>>>>> I will flesh things out further in this ticket: >>>>>> https://issues.apache.org/jira/browse/LOG4J2-1179 >>>>>> >>>>>> >>>>>>> On Mon, May 2, 2016 at 1:42 AM, Ralph Goers >>>>>>> <ralph.go...@dslextreme.com> wrote: >>>>>>> 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 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> 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> >>>>>>>>>> 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> 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/ >>>>>>>>>>> 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 >> >> >> >> -- >> Matt Sicker <boa...@gmail.com>
