Performance

One of the often-cited arguments against logging is its computational cost. This is a legitimate concern as even moderately sized applications can generate thousands of log requests. Much effort was spent measuring and tweaking logging performance. Log4j claims to be fast and flexible: speed first, flexibility second.

The user should be aware of the following performance issues.

1. Logging performance when logging is turned off.

   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:

               Log4j: 4
               Logback: 5
               Log4j 2: 3
               

   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.

   However, The method invocation involves the "hidden" cost of parameter construction.

   For example,

                 logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
               

   incurs the cost of constructing the message parameter, i.e. converting both integer i and entry[i] to a String, and concatenating intermediate strings, regardless of whether the message will be logged or not. This cost of parameter construction can be quite high and it depends on the size of the parameters involved. A comparison run on the same hardware as above yields:

               Log4j: 188
               Logback: 183
               Log4j 2: 188
               

   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.

   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:

               logger.debug("Entry number: {} is {}", i, entry[i]);
               

   Using this approach, a comparison run again on the same hardware produces:

               Log4j: Not supported
               Logback: 9
               Log4j 2: 4
               

   These results show that the difference in performance between the call to isDebugEnabled and logger.debug is barely discernible.

   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:

               if(logger.isDebugEnabled() {
                   logger.debug("Entry number: " + i + " is " + entry[i].toString());
               }
               

   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 isDebugEnabled and once in debug. This is an insignificant overhead because evaluating a logger takes about 1% of the time it takes to actually log.

   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, logging cannot be turned on for that binary. This seems to be a disproportionate price to pay in exchange for a small performance gain.

The performance of deciding whether to log or not to log when logging is turned on.

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 is first created but reduces the overhead every time the Logger is used.

Actually outputting log messages

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:

              Log4j: 1651
              Logback: 1419
              Log4j 2.0: 1542
          

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 frameworks are tested or adding calls to System.gc() between the tests can cause a variation in the reported times. However, these results show that actually writing out the events can be at least 1000 times more expensive than when they are disabled, so it is always recommended to take advantage of Log4j 2's fine-grained filtering capabilities.

Advanced Filtering

Both Logback and Log4j 2 support advanced filtering. Logback calls them TurboFilters while Log4j 2 has a single Filter object. Advanced filtering provides the capability to filter LogEvents using more than just the Level before the events are passed to Appenders. However, this flexibility does come with some cost. Since multi-threading can also have an impact on the performance of advanced filtering, the table below shows the difference in performance in two different sets of context-wide filters running on the same hardware as the previous tests using various numbers of threads.

Client vs Server

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 systems other than Windows or are run in a 64-bit JVM are automatically configured to run in "server" mode. Testing has shown that Log4j 2 benefits greatly from running in server mode and user's are strongly encouraged to configure their applications to run in server mode when using Log4j 2.

Asynchronous Logging Performance Improvements

Log4j 2 offers Asynchronous Loggers for high throughput and low latency logging. Asynchronous Loggers are implemented using the LMAX Disruptor inter-thread messaging library instead of the ArrayBlockingQueue used by Asynchronous Appenders.

Asynchronous Appenders already offered about 5 - 10 times more throughput than synchronous loggers, but this advantage remained more or less constant when more threads are logging. That is, if you double the number of threads that are logging you would expect your total throughput to increase, but this is not the case: the throughput per thread is roughly halved so your total throughput remains more or less the same. (Note that this happens even if the appender queue size is large enough to hold 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 Appenders, 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) where Asynchronous Appenders start experiencing worst-case latency spikes in the 100 millisecond range, a difference of four orders of magnitude. See Asynchronous Logging Performance for details.

The performance results above were all derived from running the DebugDisabledPerformanceComparison, FilterPerformanceComparison, and PerformanceComparison junit tests which can be found in the Log4j 2 unit test source directory.