6

I need to do logging in our application and would like to keep the time consumed due to logging as little as possible. I am thinking of using MSMQ so that the application will log into MSMQ and then I can log the messages from MSMQ to the database/files asynchronously.

Is this idea good in terms of performance? or logging to flat files synchronously using log4net is better.

Also , I am thinking of coding a logging abstraction layer so that I plug in any logging tools later without affecting other code.

Please advise.

Thanks, sveerap

Ronald Wildenberg
  • 31,634
  • 14
  • 90
  • 133
sveerap
  • 841
  • 1
  • 9
  • 20

3 Answers3

6

I would advise against this. This is a needlessly complex solution for a problem that doesn't really exist. I've used log4net in multiple projects and never saw any significant performance degradation because of it.

It's a better idea to take good care of selecting the right logging levels for each log message (DEBUG, INFO, WARN, etc). When you start your project and maybe during a short time when you're in production you log everything from DEBUG to higher levels. When you're confident everything works, you switch to INFO in the configuration. This should be enough to tackle any performance issues you may encounter with logging.

Concerning your abstraction layer, I wouldn't do this either. Log4net itself abstracts all details of the logging itself via its logger appenders. And if you really want this, you may also want to take a look at Common.Logging.

Ronald Wildenberg
  • 31,634
  • 14
  • 90
  • 133
  • Thanks for the response. I might have to log the messages to a database instead of flat files, then won't log4net take more time as it has to be done synchronously as opposed to MSMQ which can be done asynchronously. – sveerap Feb 16 '11 at 07:21
  • I don't think there is a significant performance difference between creating an MSMQ message and adding a database record. If you already have the MSMQ infrastructure in place, you may want to write a log4net `MSMQAppender` that allows you to log to MSMQ, but I still do not think it is worth the trouble. – Ronald Wildenberg Feb 16 '11 at 07:55
4

For what it's worth, there are scenarios where this isn't overkill. But, for most applications I would say that it is.

I work in an environment that is comprised of several z/OS mainframes and a variety of *nix midranges. The systems all write logging messages to a shared queue which is processed. Organisationally, it was found to provide better throughput and to ensure the consistency of the log.

With that said, I can see the advantage of using this approach for your applications. For example, developing a lot of internal applications and having a common log (for example, in the database - have a process which comes and reads the queue and writes it to the database) would allow you to aggregate all of your messages.

However, you will probably find that log4net or another .NET logging package will perfectly suit your needs.

There are advantages to both, but as everyone else has said - using MSMQ for logging is (probably) like going after a fly with a bazooka.

Sam
  • 4,219
  • 7
  • 52
  • 80
1

Honestly, MSMQ seems overkill for logging messages. Unless you absolutely need reliable delivery of the log messages, log4net seems to be a perfectly fit solution. keep also in mind that creating a message in MSMQ might take longer than actually writing to a buffered file.

You may also want to have a look at the System.Diagnostics.Trace object.

Johann Blais
  • 9,389
  • 6
  • 45
  • 65
  • Thanks for the response. I might have to log the messages to a database instead of flat files, then won't log4net take more time as it has to be done synchronously as opposed to MSMQ which can be done asynchronously. – sveerap Feb 16 '11 at 07:22