[jira] [Commented] (LOG4J2-1179) Log4j performance documentation

["Mikael Ståldal (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266730#comment-15266730 ] 

Mikael Ståldal commented on LOG4J2-1179:
----------------------------------------

Can we include GelfLayout in the layout section?

> Log4j performance documentation
> -------------------------------
>
>                 Key: LOG4J2-1179
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1179
>             Project: Log4j 2
>          Issue Type: Documentation
>          Components: Documentation, Performance Benchmarks
>    Affects Versions: 2.4.1
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.6
>
>
> Reorganize and extend performance data on the site.
> *Async Loggers Manual Page*
> Should be more focussed. Proposed changes:
> * Move _"Location, location, location..."_ section on Location Info to general Performance page (keep anchors and link to the relevant Performance page section to avoid breaking existing links)
> * Similarly, move _"Throughput of Logging With Location (includeLocation="true")"_ table with throughput results to general Performance page
> * Move _"FileAppender vs. RandomAccessFileAppender"_ section to general Performance page. (Again, keep anchors and link to new section on Performance page to avoid breaking links.)
> * Rewrite opening paragraph of Async Logger manual page to remove reference to RandomAccessFile appender
> * Rewrite section on _Latency_
> ** The histogram shows service time (more useful for users is response time: service time + wait time).
> ** Bar chart diagram on "average latency" is nonsense. Latency is not a normal distribution so terms like "average latency" don't make sense. Remove this. (A histogram showing the full range of percentiles _does_ make sense.)
> ** Bar chart diagram with max of 99.99% of observations is better than average but still has large drawbacks: this is service time (omitting the crucial wait time) and how high are the peaks in the 0.01% we did not report? Better to remove this and instead show a histogram with the full range of percentages.
> *Performance Page*
> # Briefly explain about various aspects of "performance": peak measured throughput (what kind of bursts can we deal with?), sustained throughput, and response time (service time + wait time).
> # Then show how Log4j 2 compares to the alternatives (Logback, Log4j-1.2 and JUL) on all these three performance dimensions.
> # Finally, document some performance trade-offs for Log4j 2 functionality.
> *2. Comparison to alternative logging libraries*
> Link to Async Loggers page for bursty logging. 
> Clarify that Async Appender exists to minimize dependencies but should be avoided if performance is a concern. Async Appender is NOT the default and should NOT be used for benchmarking. (I found [this loggly article|https://www.loggly.com/blog/benchmarking-java-logging-frameworks/] very frustrating in that respect.) Should probably also clarify that any benchmark that tests with only one thread doing logging is of limited use.
> For various appenders, compare Log4j2 to alternatives with regards to max sustained throughput (and separately, response time).
> * [File Appender max sustained thoughput|https://issues.apache.org/jira/browse/LOG4J2-1297?focusedCommentId=15256490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15256490]
> * Socket appender (TCP/UDP)
> * Syslog appender (TCP/UDP)
> *3. Log4j 2 functionality performance trade-offs*
> * including location
> * Cost of various layouts (HTML, XML, CSV, Pattern)
> * Cost of various Pattern Layout options
> * Cost of various appenders (File, RandomAccess File, MemoryMapped File, Console, Rewrite, other?) TODO: decide on layout for these tests.
> * Cost of various APIs/wrappers (SLF4J, Log4j1, JUL, Commons Logging)
> * JDBC appenders? - different JDBC drivers and target databases may have very different performance. May become a big project. We could do a quick comparison of the JDBC appender to the JDK Derby DB compared against FileAppender just to get an idea of max sustained throughput?
> -------------------
> Of the existing Performance page sections:
> * Briefly mention that disabled logging has no measurable cost, but de-emphasize this section by moving it down the page. 
> * Parameterized messages: use these JMH [benchmark results|https://issues.apache.org/jira/browse/LOG4J2-1278?focusedCommentId=15216236&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15216236]? (Looks like parameterized messages are currently quite expensive...)
> * I like the part about the filters because it a) compares Log4j 2 to Logback and b) considers multithreaded applications. I'll turn this into a JMH test and show the result as a bar chart.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org