.NET Zone is brought to you in partnership with:

Robert is a South African technology specialist with focus on Microsoft technologies. He is very passionate about teaching and sharing and is a Microsoft MVP & Ranger. Robert is a DZone MVB and is not an employee of DZone and has posted 75 posts at DZone. You can read more from them at their website. View Full User Profile

Is the event log (fast) enough for me?

02.12.2013
| 2440 views |
  • submit to reddit

In a recent project I was required to come up with a suggestion for logging and while the existing view of using a text file is used by many popular applications and is well understood it felt like re-inventing the wheel.


In the past I have used the great libraries of Enterprise Library orLog4Net to ensure I didn’t need to re-invent the wheel but really only to ever write to a log file. I began to question should I use the Windows Event Log rather, since it offers a lot of other features, especially around the viewer.

The viewer can not only provide a simple view, but offers ordering, filtering, exporting, remote connections (you can open the event logs on other machines), monitoring (through tools like System Center Operations Manager) and forwarding.

The big question for me has always been, can it cope with the load I want to throw at it? So to test this I wrote a small application, which is available for you to grab or comment on at Bitbucket. The application spins up a few threads (on my machine 4 is the magic number – above that there is no major improvements) and just writes as much data as quickly as possible to an event log.

Every time I have run it I have managed to get close to 40 000 writes per second! Monitoring CPU at the time, it averages between 30% to 50%, so not minor load but considering how much is happening, understandable.


There isn’t much I have that needs that sort of speed, and if I do there is ETW, so help me chant DEATH TO THE TEXT FILE, LONG LIVE THE EVENT LOG!

Published at DZone with permission of Robert Maclean, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)