Is the event log (fast) enough for me?
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 or Log4Net 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!
[...] Is the event log (fast) enough for me? | Robert MacLean [...]
Have you run into any pitfalls with the EVENT LOG.
Most of the time I've only opted to use the EVENT LOG for high level logs (WARNING, ERROR, FATAL) due to it's performance and Max Log Size issues.
Just my 2 cents.
None so far. Hopefully the 40k / second I got on my laptop puts your worry away. The second issue is max log size, and there is no worry there either as event logs have three options
1) When it gets to a pre-set size (which if you look at the code I set to 1Gb), over write the existing oldest items. This is default.
2) When it gets to a pre-set size, do nothing.
3) When it gets to a pre-set size, archive the log file and start again. Basically this removes the limit should you need to but increases risk since you may run out of disk space.
There is another option, which I linked to in the post - event log supports log forwarding, so the server it runs on automatically forwards the logs to another machine (the collector) and gets processed there. In this way you could have a dedicated logging machine and control disk/size issues centrally.
Post new comment