I\'m developing a web app, and I\'d like to log some information to help me improve and observe the app. (I\'m using Tomcat6)
First I thought I would use StringBuild
If performance is a concern, be sure to pay special attention to the pattern layout documentation and avoid expensive conversion characters such as C, F, L, and M. These require shenanigans to retrieve this info.
In place of C, use c and appropriately name your Logger objects when they are created. This means you can't inherit loggers from parent classes, but the inconvenience of redefining the logger is worth the increase to performance. F, L, and M don't have easy replacements for their functionality, but well worded log messages should be really easy to find in your source, so the need to specify the exact method, file, and line is diminished.
Finally, avoid dynamic string concatenation in your log messages. When it is necessary to use concatenation, be sure to wrap the creation of that logging string in the appropriate checker method.
private final static Logger LOG = Logger.get(MyClass.class);
...
void someMethod() {
if (LOG.isDebugEnabled()) {
LOG.debug("some really expensive string concatenation: " + someInstanceVariable + " a bunch of other text!");
}
}
The isDebugEnabled() always runs in constant time. LOG.debug() itself essentially does a isDebugEnabled() check at the beginning, but the string passed as a parameter must be fully built before that check can happen, causing an unnecessary delay when debug level is turned off.
Make sure you have a proper logging strategy. That means make sure you define what to log and have it separated into debug, trace, info, warning and error as well some others if you need them. Also make sure you give the ability to switch it on and off to enact performance/debugging as needed.
Logging can have a significant impact on a heavily used site/app, Also logging too much gives you more information than you can sort through. Logging sometimes is the only post-incident debugging tool you have so make sure you make it count.
I don't have to worry about log4j's performance even if I heavily log
Exactly. Do not optimize until your profiling results tell you to. There are cases, when logging performance is a bottleneck, but you need first to hit that case, then optimize for it.
Yes, Log4J is known to be fast, due to the conscious effort of its implementors. See also the section "Performance" at the end of this introduction to Log4J.
It must be noted that log4j suffers from numerous locking pains under heavy concurrent use.
More details and some workaround in my another answer: Production settings file for log4j?
the bottle neck should be the hard disk. your test shows roughly 1MB/s disk write speed, which is quite poor actually.