Check Performance of Event Log Queries


Summary: Ed Wilson, Microsoft Scripting Guy, talks about checking the performance of various event log queries.

Microsoft Scripting Guy, Ed Wilson, is here. One of the great things about Windows PowerShell is that I can use Windows PowerShell to see how it is doing and how to optimize it. Sometimes the difference between one query and another query can be remarkable.

So how can I do performance monitoring for a command? I use the Measure-Command cmdlet. Here is an example of such a command:

Measure-Command -Expression {Get-EventLog -LogName application}

This command uses the Get-EventLog cmdlet to read the entire contents of the application log. The output from the command is shown here:

Image of command output

If I want to compare this with the Get-WinEvent log command, I use a filter hash table that selects all entries from the application log:

Measure-Command -Expression {Get-WinEvent @{logname='application'}}

The output from this command is shown here:

Image of command output

The first command takes less than a second, and the second command takes nearly 20 seconds. Dude, that is significant.

What if I filter on event types? I only want errors. Here is the first command:

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error}

The output is shown here:

Image of command output

It is a little bit faster than the original command, but basically they are the same—less than a second difference.

Here is the same command for the Get-WinEvent cmdlet:

Measure-Command{Get-WinEvent @{logname='application';level=2 }}

The output is shown here:

Image of command output

Interestingly enough, although the “get everything from the application log” command of Get-WinEvent was really slow, it speeds up considerably when also filtering for the entry type. In fact, it came out a little faster than the Get-EventLog command.

What about when filtering with the event ID in addition to the event level? Well, here is the command for Get-EventLog:

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error -InstanceId 490}

The output tells me that basically it does not make much difference for the Get-EventLog cmdlet. 827 milliseconds or 767 milliseconds are essentially the same.

Image of command output

What about adding the event log event ID to the Get-WinEvent cmdlet?

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error -InstanceId 490}

Here is the output:

Image of command output

By adding an event ID to the query, we again speed it up a lot. 61 milliseconds as opposed to 709 milliseconds.

Note  Subsecond comparisons for Measure-Command are not really very accurate, and therefore, they should be taken with a grain of salt. The key is that it again appears to be faster.

If I add a date to the filter with Get-EventLog, it does not appear to make much difference:

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error -InstanceId 490 -After 10/1/2015}

Adding the start time to the Get-WinEvent query also does not make much difference:

Measure-Command{Get-WinEvent @{logname='application';level=2;id=490;Starttime='10/1/2015'}}

The two commands and their associated output are shown here:

Image of command output

That is all there is to using Measure-Command to check the performance of different queries. Join me tomorrow when I will begin a video recap of event log querying. 

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (1)

  1. MockMyBeret says:

    I haven’t tried these out, but could there be some caching that we could attribute the highly disparate times of get-winevent to?

Skip to main content