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.


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.


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:

Jennifer Marsh

Jennifer Marsh

Share Your Thoughts


  • 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

      2 years ago


      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

    2 years 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

      1 year 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

      1 year ago

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

  • Jeff Varszegi

    10 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

      5 months 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:

      • Linda Somme

        4 months ago

        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

    5 months 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

      4 months 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:

  • Steve Hibbert

    5 months 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

      5 months ago

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

      • Steve Hibbert

        4 months ago

        Further to this, Rolf Kristensen of NLog has explained that NLog can be very flexibly configured, and he has kindly optimised my config so that it is like my Log4Net config. For reference, I had to use keepFileOpen=”true” and concurrentWrites=”false” to optimise for synchronous single windows file logging. Now the NLog and Log4Net performance is near identical, circa 450 milliseconds to write 10,000 lines, probably because they are both writing text to a Windows file in the same mode. That is going direct to the logger though, not through ILogger. There seems to be huge overhead making calls through the MS facade, regardless of the logging system behind it.

    • Rolf Kristensen

      4 months ago

      NLog File-target uses KeepFileOpen=false by default, which is very slow. Try and change to KeepFileOpen=true. Also it is a very good idea to enable <targets async=”true”>.