Logging is one of those things that performance engineers either love or hate—or (usually)
both. Whenever I'm asked why a program is running badly, the first thing I ask for are any
available logs, with the hope that logs produced by the application will have clues as to what
the application was doing. Whenever I'm asked to review the performance of working code,
I immediately recommend that all logging statements be turned off.
There are multiple logs in question here. GC produces its own logging statements (see
aged by the JVM. Even in production code, GC logging (with the -XX:+PrintGCDetails
flag) has such low overhead and such an expected large benefit if something goes wrong that
it should always be turned on.
Java EE application servers generate an access log that is updated on every request. This log
generally has a noticeable impact: turning off that logging will definitely improve the per-
formance of whatever test is run against the application server. From a diagnosability stand-
point when something goes wrong, those logs are (in my experience) not terribly helpful.
However, in terms of business requirements, that log is often crucial, in which case it must
be left enabled.
Although it is not a Java EE standard, many application servers support the Apache
mod_log_config standard, which allows you to specify exactly what information is logged
for each request (and servers that don't follow the mod_log_config syntax will typically
support some other log customization). The key here is to log as little information as possible
and still meet the business requirements. The performance of the log is subject to the amount
of data written.
In HTTP access logs in particular (and in general, in any kind of log), it is a good idea to log
all information numerically: IP addresses rather than hostnames, timestamps (e.g., seconds
since the epoch) rather than string data (e.g., “Monday, June 3, 2013 17:23:00 -0600”), and
so on. Minimize any data conversion that will take time and memory to compute so that the
effect on the system is also minimized. Logs can always be postprocessed to provide conver-
There are three basic principles to keep in mind for application logs. First is to keep a bal-
ance between the data to be logged and level at which it is logged. There are seven standard
logging levels in the JDK, and loggers by default are configured to output three of those
levels ( INFO and greater). This often leads to confusion within projects: INFO -level messages
sound like they should be fairly common and should provide a description of the flow of an