Microsoft Enterprise Library Logging Block compared to Log4net follow up

I'd like to thank Tom Hollander and Hisham Baz for their responses to my post comparing Log4net and the EntLib logging block. Tom did an excellent job of pointing out how every app has different requirements, and it is dangerous to take performance numbers alone as the sole criteria for selecting a technology. I would also like to thank Hisham Baz for taking the time to profile the block and identify some possible optimizations that could be made.

I listened in on a webcast on the Enterprise Library logging block the other day and was encouraged to hear that the EntLib team is planning to address many issues in the next release. The EntLib team refers to the upcoming version as "vNext". This is a ".NET 2.0 version, due out at or around the same time as .NET 2.0 / VS 2005". My concern is that it is planned to require .NET 2.0. Many shops will take a long time to move to to .NET 2.0 and as such I think that the EntLib team is missing an opportunity here. I would love to see a patch get released before vNext with the performance optimizations Hisham Baz mentions and a way to programmatically check the logging level ahead of making a logging call. These would be necessary before we could consider switching to it for our application. It could be 1-1/2 years before we can migrate to .NET 2.0.

The webcast was very informative and I learned a clever trick/hack to work around one issue. When using the configuration tool on an ASP.NET application, web.config is re-written which restarts the web app. During the Q&A of the webcast, the EntLib team proposed a clever why-didn't-I-think-of-that work-around by simply making a copy of the web.config and opening that. If all you are changing is logging settings, it should work fine.

I want to clarify a few things about where I'm coming from on this comparison between log4net and EntLib's logging block:

- I love the work the P&P team is doing on these blocks. I've used the previous generation of blocks extensively, and I think they're great. Although I don't have as much experience with it yet, EntLib looks great too. The Enterprise library is more than just logging, so don't discount the entire library just because of my silly little post on one little part of it.

- I don't represent log4net, or have anything to do with the project other than being a user of it. I have had good luck using log4net so far, but am certainly not married to it...in fact I did the initial comparison with hopes to replace log4net it with EntLib's logger. The fact that there have been no releases of log4net in such a long time really bothers me. I sincerely want to move to EntLib's logger, unfortunately the significantly slower performance and missing features made EntLib's logger less attractive for the high-volume ASP.NET application we are working on. Your mileage may vary. Tom Hollandar's point that what's appropriate for one isn't necessarily appropriate for all is spot-on, and you need to evaluate it yourself.

- One of my goals for posting the comparison with log4net was to make EntLib better so eventually I'd be able to move to it because I think there's more of a future in the MS backed library.

Another performance comparison

The performance comparison of Enterprise Library Logging block to Log4net I detailed in my previous post (logging 10000 messages in a tight loop) was admittedly unrealistic, so I tried to think of a different way I could compare the performance that may be a little closer to typical. I am interested in knowing the cost of logging on the response time of the pages in our ASP.NET application. In the scenario I wanted to test, each page request logs one message. This is still far more logging than you would probably want in production, however when troubleshooting with verbose logging turned on, it is possibly going to be even more than this.

I wrote a very simple ASP.NET web application with an empty aspx page that does no logging (for a baseline), an empty aspx page that logs a message with log4net, and another empty aspx page that logs the same message with EntLib. Then I wrote a set of ACT (Application Center Test) tests that request each page variation repeatedly for 3 minutes with a 5 second warm-up time. This time instead of running the tests on my lowly laptop, I ran them on a server that would be more typical of production. I then compared the average number of requests per second and you can see my results below. Because in this test the pages are completely empty and doing no work whatsoever, it is important to point out that logging will become an increasingly more insignificant part of each request the more work each page does. If you have a heavy page that is going to the database, the logging time drops to a negligible amount of time, so in most apps we're just splitting hairs here.

Just as I did in the previous tests, I used an empty sink/appender for one set of tests to simply test the overhead of the logging frameworks themselves. This factors out the cost of writing to a file etc. Then later I configured each logger to log to a text file with equivalent minimal layout pattern and ran the tests again. Here are the numbers I saw: