I have a service application that is processing client requests over TCP and writing any events into Windows EventLog. Since this application is expected to service many clients and lots of requests from each client in a short amount of time (let's say between 1 and 50 requests per second), I'm curious to know how intensive (CPU wise and time wise) and how fast can writing into Windows EventLog be?
More specifically, how intensive are the operations of connecting to, reading from and writing to EventLog?
I made a test with my 2 event log classes, one writing to file (each log_event() writes to and flushes already opened file) and one based on EventLog (ReportEvent() call on already registered EventSource). In my case file log was about 10 times faster than EventLog. In multithread envirnonment I would add critical section to protect writing to file.
In my opinion files are better: they are easily parsed in tools such as grep. Speed is less important for me.
Don't do that. The event log is not designed for such an activity:
- It has a maximum size.
- When the maximum size is reached, it can overwrite events or stop logging, depending on settings (recent Windows can also archive the log and start a new one). If events are not overwritten, they can fill your partition or block other applications until the logs are manually cleared.
The event log is not a general logging facility. It should be used to report errors, situations that needs attention, and even informative reports, but not every little bit of information one has to write somewhere. If you have heavt log needs, use your own log facilities and report issues - if any - in the event log with a "pointer" where to find detailed data if needed.
NOTE: if really the event log is needed, at least the application should use its own log destination, not one of the standard ones (application or even worse system). This way it won't impact other applications operations, and won't "hide" other application events "flooding" the log with its events, making more difficult to spot the others without looking for them.
Event Tracing for Windows would likely be a better repository for this level of traffic.
Event Tracing for Windows (ETW) is an
efficient kernel-level tracing
facility that lets you log kernel or
application-defined events to a log
file. You can consume the events in
real time or from a log file and use
them to debug an application or to
determine where performance issues are
occurring in the application.
Sample pseudo-code:
const
MyApplicationProviderGUID: TGUID = '{47A0DECE-4DCF-4782-BCF4-82AECA6BAAB7}';
private
FETWRegistrationHandle: THandle;
...
EventRegister(MyApplicationProviderGUID, nil, nil, {out}FETWRegistrationHandle);
...
EventWriteString(FETWRegistrationHandle, 0, 0, 'Hello');
EventWriteString(FETWRegistrationHandle, 0, 0, ', ');
EventWriteString(FETWRegistrationHandle, 0, 0, 'world');
EventWriteString(FETWRegistrationHandle, 0, 0, '!');
...
EventUnregister(MyApplicationProviderGUID);
Maybe Microsoft Message Queuing (MSMQ) is an alternative to the Windows EventLog. It is available in all current versions of Windows, and offers high speed, loosely coupled messaging.
