logging-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mattsic...@apache.org
Subject svn commit: r1585224 - /logging/log4j/log4j2/trunk/src/site/xdoc/performance.xml
Date Sun, 06 Apr 2014 01:45:59 GMT
Author: mattsicker
Date: Sun Apr  6 01:45:59 2014
New Revision: 1585224

URL: http://svn.apache.org/r1585224
Add XSD and various mark-up modifications.

  - Fixed some typos.
  - Converted the <b>Foo</b><br/> parts to <h3>Foo</h3>.
    ~ Though these should probably just be converted to subsections.
  - Fixed XML error involving nesting <pre/> inside a <p/> tag.


Modified: logging/log4j/log4j2/trunk/src/site/xdoc/performance.xml
URL: http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/src/site/xdoc/performance.xml?rev=1585224&r1=1585223&r2=1585224&view=diff
--- logging/log4j/log4j2/trunk/src/site/xdoc/performance.xml (original)
+++ logging/log4j/log4j2/trunk/src/site/xdoc/performance.xml Sun Apr  6 01:45:59 2014
@@ -16,7 +16,9 @@
     limitations under the License.
+<document xmlns="http://maven.apache.org/XDOC/2.0"
+          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+          xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
     <author email="rgoers@apache.org">Ralph Goers</author>
@@ -33,25 +35,27 @@
       <p>The user should be aware of the following performance issues.</p>
-          <b>Logging performance when logging is turned off.</b>
-          <br/>
+          <h3>Logging performance when logging is turned off.</h3>
           <p>When logging is turned off entirely or just for a set of Levels, the cost
of a log request consists of
             two method invocations plus an integer comparison. On a 2.53 GHz Intel Core 2
Duo MacBook Pro
-            calling isDebugEnabled 10 million times produces an average result in nanoseconds
of: <br />
+            calling isDebugEnabled 10 million times produces an average result in nanoseconds
             Log4j: 4
             Logback: 5
             Log4j 2: 3
+          <p>
             The numbers above will vary slightly from run to run so the only conclusion that
should be
             drawn is that all 3 frameworks perform similarly on this task.
           <p>However, The method invocation involves the "hidden" cost of parameter
           <p>For example,
+          </p>
               logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
+          <p>
             incurs the cost of constructing the message parameter, i.e. converting both integer
             <code>i</code> and <code>entry[i]</code> to a String,
and concatenating intermediate strings,
             regardless of whether the message will be logged or not.
@@ -60,12 +64,13 @@
             depends on the size of the parameters involved.
             A comparison run on the same hardware as above yields:
+          </p>
             Log4j: 188
             Logback: 183
             Log4j 2: 188
+          <p>
             Again, no conclusion should be drawn regarding relative differences between the
frameworks on
             this task, but it should be obvious that it is considerably more expensive than
simply testing
             the level.
@@ -73,33 +78,37 @@
             The best approach to avoid the cost of parameter construction is to use Log4j
2's formatting
             capabilities. For example, instead of the above write:
+          </p>
             logger.debug("Entry number: {} is {}", i, entry[i]);
+          <p>
             Using this approach, a comparison run again on the same hardware produces:
+          </p>
             Log4j: Not supported
             Logback: 9
             Log4j 2: 4
+          <p>
             These results show that the difference in performance between the call to isDebugEnabled
-            logger.debug is barely discernable.
+            logger.debug is barely discernible.
           <p>In some circumstances one of the parameters to logger.debug will be a
costly method call that
             should be avoided if debugging is disabled. In those cases write:
+          </p>
             if(logger.isDebugEnabled() {
                 logger.debug("Entry number: " + i + " is " + entry[i].toString());
-          </p>
           <p>This will not incur the cost of whatever the toString() method needs to
do if debugging is disabled.
             On the other hand, if the logger is enabled for the debug level, it will incur
twice the cost of
             evaluating whether the logger is enabled or not: once
             in <code>isDebugEnabled</code> and once in <code>debug</code>.
This is an insignificant
             overhead because evaluating a logger takes about 1% of the time it takes to actually
-          <p>Certain users resort to preprocessing or compile-time
+          <p>Certain users resort to pre-processing or compile-time
             techniques to compile out all log statements. This leads to perfect
             performance efficiency with respect to logging. However, since the
             resulting application binary does not contain any log statements,
@@ -109,8 +118,7 @@
-          <b>The performance of deciding whether to log or not to log when logging
is turned on.</b>
-          <br/>
+          <h3>The performance of deciding whether to log or not to log when logging
is turned on.</h3>
             Unlike Log4j, Log4j 2 Loggers don't "walk a hierarchy". Loggers point directly
to the
             Logger configuration that best matches the Logger's name. This incurs extra overhead
when the Logger
@@ -118,20 +126,19 @@
-          <b>Actually outputting log messages</b>
-          <br/>
+          <h3>Actually outputting log messages</h3>
           <p>This is the cost of formatting the log output and sending it to its target
destination. Here again,
             a serious effort was made to make layouts (formatters) perform as quickly as
possible. The same
             is true for appenders. One of the fundamental tenets of Log4j 2 is to use immutable
objects whenever
             possible and to lock at the lowest granularity possible. However, the cost of
actually formatting and
             delivering log events will never be insignificant. For example, the results of
writing to a simple log
             file using the same format using Log4j, Logback and Log4j 2 are:
-            <pre>
+          </p>
+          <pre>
               Log4j: 1651
               Logback: 1419
               Log4j 2.0: 1542
-            </pre>
-          </p>
+          </pre>
             As with many of the other results on this page the differences between the frameworks
above should be
             considered insignificant. The values will change somewhat on each execution and
changing the order the
@@ -142,8 +149,7 @@
-          <b>Advanced Filtering</b>
-          <br />
+          <h3>Advanced Filtering</h3>
             Both Logback and Log4j 2 support advanced filtering. Logback calls them TurboFilters
             Log4j 2 has a single Filter object. Advanced filtering provides the capability
to filter
@@ -202,8 +208,7 @@
-          <b>Client vs Server</b>
-          <br />
+          <h3>Client vs Server</h3>
             Java supports a "client" and a "server" mode of operation. By default, applications
that are
             run in Java 5 on machines with 2 CPUs or more and 2GB of memory or more on operating
@@ -213,8 +218,7 @@
-		<b>Asynchronous Logging Performance Improvements</b>
-		<br />
+		<h3>Asynchronous Logging Performance Improvements</h3>
 		Log4j 2 offers Asynchronous Loggers for high throughput and low latency logging.
 		Asynchronous Loggers are implemented using the
@@ -231,13 +235,13 @@
 		all messages logged during the test, so this is not caused by disk I/O.)
 		Asynchronous Loggers have significantly higher throughput than the legacy Asynchronous
-		especially in multithreaded scenarios. In one test with 64 threads,
+		especially in multi-threaded scenarios. In one test with 64 threads,
 		Asynchronous Loggers were 12 times faster than the fastest Asynchronous Appender,
 		and 68 times faster than the fastest synchronous logger.
 		In addition to throughput, Asynchronous Loggers have attractive latency characteristics.
 		Not only is average latency lower compared to Asynchronous Appenders,
-		but when increasing the number of application threads that do logging, 
-		worst-case latency remained almost constant (10 - 20 microseconds) 
+		but when increasing the number of application threads that do logging,
+		worst-case latency remained almost constant (10 - 20 microseconds)
 		where Asynchronous Appenders start experiencing worst-case
 		latency spikes in the 100 millisecond range, a difference of four orders of magnitude.
 		See <a href="manual/async.html#Performance">Asynchronous Logging Performance</a>
for details.

View raw message