Tempos atras estava estudando um pouco sobre frameworks de Log e recentemente retomei meus estudos e resgatei um artigo interessando que faz um Benchmarking com alguns Frameworks de mercado.
Frameworks Testados:
- Log4net
- ELMAH
- NLog
- Microsoft Enterprise Library
- NSpring
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.
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 »
Fonte: https://www.loggly.com/blog/benchmarking-5-popular-net-logging-libraries/