Using msmq for asynchronous logging

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.