4

I am considering logging business events in a J2EE web application by using Java logging and FileHandler.

I am wondering whether that could cause a performance bottleneck, since many log records will be written to one file.

What are your experiences and opinions?

Is logging a busy web application to one file with Java logging and FileHandler likely to become performance bottleneck?

vaultah
  • 44,105
  • 12
  • 114
  • 143
TheLameProgrammer
  • 4,037
  • 5
  • 19
  • 16

5 Answers5

4

It all depends on how much log statements you add. If you add logging after every line of code then performance will must certainly degrade.

Use logging for the important cases, set the correct logging level for your current purposes (testing or actual deployment) and use constructions like

if (Logger.isDebugEnabled()) {
   Logger.debug("Value is " + costlyOperation()")
}

to avoid calling code that is costly to run.

You might also want to check this article

THelper
  • 15,333
  • 6
  • 64
  • 104
3

In order to avoid generalities like "it depends" or "a little" etc. you should measure the performance of your application with and without the logging overhead. Apache JMeter can help you generate the load for the test.

The information you can collect through logging is usually so essential for the integrity of the application, that you can not operate blindly. There is also a slight overhead if you use Google Analytics, but the benefits prevail.

In order to keep your log files within reasonable sizes, you can always use rotating log files.

Costis Aivalis
  • 13,680
  • 3
  • 46
  • 47
1

I think that JavaRevisited blog has a pretty good post on a problem with performance: Top 10 Tips on Logging in Java

Boris Pavlović
  • 63,078
  • 28
  • 122
  • 148
1

In a recent project, I log audit events to a database table and I was concerned about performance, so I added the ability to log in 'asynchronous' mode. In this mode the logger runs in a low-priority background thread and the act of logging from the main thread just puts the log events onto a queue which are lazily retrieved and written by the background logging thread.

This approach will only work, however, if there are natural 'breaks' in the processing; if your system is constantly busy then the queue will never be emptied. One way to solve this is to make the background thread more active depending on the number of the log messages in the queue (an enhancement I've yet to implement).

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
1

You should:

  1. Define an appropriate metric of performance (e.g., responsiveness, throughput, etc.). Then you should measure this metric with all logging turned off and then on. The difference would be the cost of logging.

  2. Then you should experiment with different logging libraries and the modes they provide and document the observed differences.

In my personal experience, for all the three projects I worked on, I found that asynchronous logging helped improve the application throughput a lot. But the same may not hold for you, so make sure you make your decision after careful measurements.

The following does not directly relate to your question.

I noticed that you specifically mentioned business logging. In this case, you may also want to keep logging relevant and clean, in case you find your log files are growing huge and difficult to understand. There is a generally accepted design pattern in this area: log as per function. This would mean that business logging (e.g., customer requested a refund) goes to a different destination, interface logging would go to another destination (e.g., user clicked the upvote button != user upvoted an answer), and a cross system call would go to another destination (e.g., Requesting clearance through payment gateway). Some people keep a master log file with all events as well just to see a timeline of the process while some design log miners/scrappers to construct timelines when required.

Hope this helps,

Apoorv
  • 1,091
  • 6
  • 19