Performance of Logging Application Block

Topics: Logging Application Block
Mar 6, 2007 at 4:28 PM
Edited Mar 6, 2007 at 4:28 PM
I'm considering using the Logging Application block in my project but I'm concerned about the performance impact of logging.

As I understand the documentation I could use the configuration of my application to control the logging when the application is deployed. By using this feature I can control the amount of information that is logged and where it is logged.

My plan is to introduce many trace messages to be able to debug my application in the field. When I'm not using these messages they should be turned off. The amount of messages is approx. 50 - 100 messages per second

My concern is that even when turned off the trace messages might introduce a performance problem.

Is there any information on the possible performance issues of the Logging Block? Any tips to keep the performance impact to a minimum?

Thank you for any input

/ Henrik

Mar 15, 2007 at 5:19 PM
I have found if Tracing will cause significant performance bottlenecks.
Tracing is an off shoot of Logging so I would expect the same.
Mar 15, 2007 at 5:30 PM
Edited Mar 15, 2007 at 5:31 PM
We've done a lot of testing and tuning to maximize the performance of the logging block, especially when logging is turned off. When logging is on, much of the cost will come down to the real cost of the underlying log mechansim (e.g. writing to a file or the event log).

I don't believe there is any significant cost to tracing when it is turned off. When using the Logger, one thing to keep in mind is that you want to avoid gathering "expensive" data for a log message if logging may be disabled. The Logger.ShouldLog method provides one way of testing the filter status before populating a LogEntry object.

It's not possible for anyone outside your team to give a reliable answer as to whether the performance of the block is acceptable for your circumstances. The performance will be highly dependent on your environment and application, and the definition of acceptable performance will also vary greatly from application to application. So ultimately the best thing to do is do understand your performance goals and test your application in your environment to see if you can meet these.

Hope this helps