Blog .NET

Benchmarking 5 popular .NET logging libraries

By Jennifer Marsh 12 Jan 2016

Several logging frameworks promise .NET coders a “five-minute setup and start logging” solution for their projects. We decided to test these frameworks to identify speed and convenience between them. We added convenience into the equation because most .NET coders know that they can write events to the Windows Event Viewer without implementing any extra libraries. This is the ultimate convenience and reliability. However, writing to the Event Viewer doesn’t always work for some applications – for instance, you might want to write events to a log file to share with other departments or run analytics against a group of logs.

What Logging Frameworks We Tested

We decided to test the top five logging frameworks on the market:

If you’ve ever worked with enterprise logging for .NET, you probably recognize one or two of these libraries. For this test, we wrote error events to files for each framework test, although ELMAH automatically writes to files unless you specifically tell it to log to SQL. ELMAH’s SQL integration makes it one of our personal favorites, but we wanted to keep the playing field level and only use local files.

Our Testing Environment

We wanted to give these benchmark tests an environment that’s representative of the real world, so we tested them on a server hosting three web applications. The environment also hosts SQL Server and MySQL for the three applications. To simulate CPU load, we still set up a separate threaded process that generated prime numbers while the tests were run and timed. The work environment accounts for higher numbers than other benchmarks, but we find it is more true-to-life than simple prime number generation.

Our production server is a Windows 2008 server with 8GB of RAM and an i5 Intel processor with four cores, one core for each thread. The applications were created using Visual Studio 2012. Log4net, NLog, Microsoft Enterprise Library, and NSpring were all benchmarked on console applications. ELMAH is a web logger, so this application was run against a web application in .NET 4.5. We also used C# as the primary language framework.  

We did not make many configurations to the frameworks themselves. We chose libraries available in NuGet, so developers didn’t need to download specific libraries and integrate DLLs and third-party solutions into the main project.

The project consisted of only the necessary libraries for .NET to compile and execute the code. The code contained one loop that iterated through 100,000 write debug events for each framework. A separate method handled the prime number thread.

We ran three tests on each framework and used the average results.

Our Test Results

First, take a look at the graph below, and you’ll see the clear winner.

netchart

NLog was the fastest, and we have to say that it was one of the most convenient logging methods. NLog truly did stand by its claim that you could start logging events in minutes. Getting NLog to work with the application took two lines of code: one line to instantiate the main logger class, and the other to log the events. Not only was it easy to set up, but it only took about 9 seconds to complete 100,000 iterations.

Log4net was just as convenient, but it lost in terms of performance. We tried both debug and error events with log4net, and debug logging was actually faster than standard error events. Compared to its competitors, log4net could use some performance tweaking from the developers especially for enterprise applications. It was just as convenient as  NLog, but it couldn’t compete on performance.

Our third favorite is NSpring. NSpring was easy to set up, but it required much more code to work with it. You must open and close NSpring logger events, which you don’t need to do with the others. A few more lines of code in a simple application aren’t too much of a hassle, but opening and closing logger variables can be tedious for enterprise applications.

Of the frameworks we tested in a console application, the native Microsoft Enterprise Library was our least favorite. It has the second fastest times, but it was extremely inconvenient. Microsoft recently changed the way its framework works from version 5 to 6. In version 5.0, the coder could make a static call to log functions, but we encountered numerous obstacles to get EntLib to work with version 6.0. The setup time for EntLib downgrades this library even though it was the second fastest.

The final framework is ELMAH. ELMAH was originally our favorite until we tested NLog. ELMAH is a web logger, so it functions a bit differently than the others. It writes to an XML file by default, which could also explain some of its lag.

Conclusion

For heavy-hitting applications that require file logging and speed, NLog was clearly the winner. NLog also has good support from the community with integrations for log management solutions like Loggly. If for any reason NLog isn’t your choice, go with NSpring instead. These two frameworks are clearly the fastest. We would have chosen log4net as our top choice had it not been for the slow performance. It was one of the easiest to set up.

All of these frameworks are available in NuGet, so you can try them out for yourself.


 

Related Reading: Benchmarking Java logging frameworks »

Jennifer Marsh

Jennifer Marsh

Share Your Thoughts

16 comments

  • Thomas Ardal

    2 years ago

    Comparing logging frameworks like NLog and Log4net with ELMAH is like comparing oranges and apples. Two different tools with different purposes. ELMAH logs 50 times more data that NLog and log4net, why it is of course slower. Your conclusion is similar to saying “querying objects in memory is faster than querying through a database, why you should always chose to keep your data in memory”. Use NLog, log4net or similar if you need to log debug, information, error messages etc. Use ELMAH if you want to log all uncaught exceptions on your website including detailed contextual information.

    • Karen Sowa

      Karen Sowa

      2 years ago

      Thomas,

      Here is the reply from Jennifer:

      You have a point, but if ELMAH is slower due to higher overhead, then it’s still worth benchmarking against other tools that could be easier to use and faster thank a “heavier” logging system.

  • Armin

    2 years ago

    Thanks Jennifer, it was a good read.

  • Alberto

    1 year ago

    Thanks for sharing Jennifer.
    I actually designed and ran quite a lot of benchmarks and I noticed that performance greatly depends on configuration of logging systems so I think you should write also the configuration of the logging systems under test.
    Anyway I never found such a difference between NLog and Log4net so I’m really curious to see your NLog targets vs Log4net appenders configuration.

    • Linda Somme

      10 months ago

      From Jennifer:
      In this case, the default configurations were used. As the other poster pointed out, your numbers could be different if you use different asynchronous settings.

  • Greg Sohl

    1 year ago

    Interesting that you included nSpring since it hasn’t been touched by the author in over 10 years. Thankfully, it still work as is. It compiles in .NET 4.5.2 and runs well there. We’ve been using it since about 2005 in wide-ranging production environments and have always been happy with it’s features and performance.

  • CapthChris

    1 year ago

    Was log4net tested with the async appender?

    • Linda Somme

      10 months ago

      Response from Jennifer Marsh:
      No, for this benchmark the default configurations were used.

  • Jeff Varszegi

    6 months ago

    As the developer of NSpring, I stumbled across this article by accident. It’s neat to see someone still using it; for a long time I got sporadic contacts from people continuing to use it in high-performance environments. I’ve been toying with the idea of developing a next-gen logging library sometime in the next year, as I’d write the code much differently today due to better compiler support for certain aspects of performance, plus ideas for new features.

    I see Serilog as getting more popular by the day, but maybe it was too new at the time this was written. Also, I agree with a previous poster that log4net should have been tested in async mode for a true performance apples-to-apples comparison.

    • Ivan Pointer

      3 weeks ago

      I’ve actually just launched a next-gen logging framework. I’ve named it NuLog. I’m actually looking for contributors to help too.

      Here’s a blog post announcing it:

      http://blog.cpsoftworks.com/2017/07/nulog-new-breed-of-logging-framework.html

      • Linda Somme

        2 weeks ago

        Ivan,
        Thanks for pointing this out. Our product management team left a comment on your blog. It would be great to know how NuLog is different from what`s currently available in rsyslog.

  • Fareed

    4 weeks ago

    I have created two separate projects one with Nlog and another with log4net for testing performance gain with their default configurations.
    I have a function that logs 2k lines.
    Log4net logged that 2k lines in approx 285 ms whereas Nlog logged same text within 7142 ms.

    Maybe I’m missing something, can anyone provide more detail on which they mentioned that NLog is better in performance than log4net

    • Linda Somme

      2 weeks ago

      Interesting work, Fareed. Nlog performed better in the particular test done here, but Loggly supports Log4Net because of its popularity. You can see our docs here:
      https://www.loggly.com/docs/net-logs/

  • Steve Hibbert

    2 weeks ago

    I would love to see this re-visited, with AspNetCore. I ran some tests with NLog vs Log4Net, I set up a concurrent queue of data that loaded ILogger messages, and wrote a separate thread to chew the queue synchronously, writing 10000 lines. I found NLog took 15 seconds to write to the log file, and Log4Net took less than 1 second. I was shocked, as I had wanted to use NLog, it being more modern. I would suggest, test your code yourself in a loop before committing to a log system, and bear in mind, they will change over time too…

    • Linda Somme

      2 weeks ago

      Good suggestion Steve! We’ll try to do an update soon.

Shares