Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In many of the services I work on there are a lot of logging being done. The services are WCF services(mostly) which use the .NET EventLogger class.

I'm in the process of improving these services' performance, and I got to think that logging asynchronously would benefit performance.

I'm unaware to what happens when multiple threads ask to log, and it if creates a bottleneck, but even if it doesn't I still think that it shouldn't interfere with the actual process being executed.

My thoughts are that I should invoke the same log method I call now but do so using a new thread, while continuing with the actual process.

Some questions about that:

Is it ok?

Are there any downsides?

Should it be done in a different way?

Maybe its so fast that it doesn't even worth the effort?

share|improve this question
    
Have you profiled the runtime(s) to know that logging has a measurable effect on performance? Computers are just too complex to just think that something might be slow, measure twice and cut once is good advice in any profession =) –  Patrick Hughes May 20 '12 at 15:10
    
@PatrickHughes - some stats from my tests on one specific request: 61(!!) log messages, 150ms before doing some sort of simple threading, 90ms after. so it is 40% faster. –  Mithir May 21 '12 at 10:14

2 Answers 2

Key factors to consider are your need for reliability in the logfiles and the need for performance. Refer downsides. I think this is a great strategy for high performance situations.

Is it ok - yes

Are there any downsides - yes - depending on the criticality of your logging and your implementation any of the following could occur - logs written out of sequence, log thread actions not complete before event actions complete. (Imagine a scenario where you log "starting to connect to DB" and you then crash the server, log event may never get written even though the event has occurred (!))

Should it be done in a different way - you might want to look at Disruptor model as it's almost ideal for this scenario

Maybe its so fast that it deosn't even worth the effort - disagree. If yours is an "application" logic, and the only thing you do is write logs of the activity - then you will be orders of magnitude lower latency by offloading logging. If however you rely on a 5sec DB SQL call to return before logging 1-2 statements, the benefits are mixed.

share|improve this answer

I think logging is generally a synchronous operation by it's nature. You want to log things if they happen or if they don't depending on your logic, so in order to log something, that thing needs to be evaluated first.

Having said that, you can improve your application's performance by caching logs and then creating a thread and saving them to files when you have a CPU bound operation.

You need to identify your checkpoints cleverly so you don't lose your important logging information during that cache period.

If you want to have a performance boost in your threads you need to balance IO operations and CPU operations.

If you create 10 threads that all do IO, then you won't get a performance boost.

share|improve this answer
    
How would you suggest caching logs? there are request-specific items in most log messages in order to identify them, in my service exact same requests rarely occur. –  Mithir May 22 '12 at 5:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.