Many customers include logging or tracing capabilities in their large applications. At times we've seen situations where applications perform poorly and one of the issues was the amount of resource being consumed by application traces that developers forgot to remove before conducting the performance evaluation. You can minimize performance problems related to logging overhead by following one simple rule: make sure any logging done from the main line path of your production applications can be turned on or off without regenerating your program.
The following table illustrates the importance of making your log invocations conditional. The table lists some measurements made using the simple logging library attached to entry. The log library includes a logging control switch that can be used to turn logging on and off.
|Scenario repeated one million times||Java Time In Seconds||Cobol Time In Seconds|
|Library writes log record to file||260||360|
|Library log function checks switch and returns without writing record to file||0.2||1|
|Client checks global library switch and does not invoke log function||0.1||0.7|
|Client checks local copy of global library switch and does not invoke log function||0.01||0.01|
- The overhead of checking a switch is very small compared to the overhead of writing log or trace records. It's reasonable to leave logging or tracing calls in a production program as long as the actual writing of the log entries can be turned on or off.
- Logging of application failures or exceptions should not be conditional. This will not hurt performance as long as the logging is down on an exception path. The logging library includes log error functions whose behavior is not controlled by the logging switch.
- Do not draw any conclusions about the relative merits of Java and Cobol from the table. The measurements were taken on different machines and comparisons between the two languages for the same scenario are not meaningful.