PowerShell v2 Get WinEvent Filtering Performance Testing and Analysis

Having been on an optimization and performance testing kick for the past week or so I stumbled across one I hadnt seen yet. Get-WinEvent can be a hog at times, so, I avoid it unless I must, particularly when hunting for specific conditions. To date I have used Get-WinEvent with a pipelined Where approach. Slow to say the least. While reading Get-Help I found an example that highlighted some filtering approaches that can significantly improve performance:

• -FilterHashTable
• -FilterXML
• -FilterXPath

Not being familiar with any of these approaches I ran example 14 in the v2 Get-Help for Get-WinEvent and did some testing. I did make a minor modification to the on-the-box help examples to have data I could use to get results. Here is my approach:

Clear-Host

$test1 = {

       # Use the Where-Object cmdlet

       $yesterday = (get-date) - (new-timespan -day 1);

       $where = get-winevent -logname "application" | where {$_.timecreated -ge $yesterday}

}

$test2 = {

       # Uses FilterHashTable

       $yesterday = (get-date) - (new-timespan -day 1)

       $filtertable = get-winevent -FilterHashTable @{LogName=application; StartTime=$yesterday}

}

$test3 =

{

       # Use FilterXML

       $filterxml = get-winevent -FilterXML "*[System[TimeCreated[timediff(@SystemTime) <= 86400000]]]"

}

$test4 =

{

       # Use FilterXPath

       $filterxpath = get-winevent -LogName "application" -FilterXPath "*[System[TimeCreated[timediff(@SystemTime) <= 86400000]]]"

}

$tests = @(

       $test1,

       $test2,

       $test3,

       $test4

)

1..10 | % {

       "Iteration $_";

       $tests |

       Foreach-Object {

              (Measure-Command -Expression { & $_  }).Ticks

       }

       ""

}

When I run it I get a nice set of results. Here they are in a relatively pretty format:

Iteration	Where	FilterHashTable	FilterXml	FilterXpath
1	493014972	3749254	4855395	5986625
2	593577895	3861254	5235727	4911358
3	520402676	7081213	6600362	6964718
4	617752316	4202329	5188378	5189118
5	496873977	4888834	4751030	5445491
6	511961827	3755366	5036335	5184823
7	818546428	6821936	12815080	13361985
8	566443409	3830192	5188369	5606259
9	492985827	4348790	4967646	5845117
10	492653208	4150840	5108303	5153839
Average	560421253.5	4669000.8	5974662.5	6364933.3

 Based on these figures, -FilterHashTable is significantly faster. Assuming Where as a baseline, the other three are faster by 90-120 times. In fact, relative to the Where, each is listed below as a percentage and a figure representing the number of times faster than Where each approach happens to process:

• FilterHashTable: 0.833% - 120 times faster than Where
• FilterXml: 1.066% - 94 times faster than Where
• FilterXPath: 1.1336% - 88 times faster than Where

Gaining improvements in performance like this should have people jumping off the Where ship like the Titanic. For sysadmins searching logs on regular basis drops in processing time like this could be significant. Plus, the -FilterHashTable option, to me at least, seems to be the easiest by far. You dont need to know XPath OR be able to hack XML. Just create a hashtable with your parameters/argument pairs and let it run.

NOTE: In the help the -FilterXml has a typo. Instead of using <= it should use <= since the < character is interpreted as XML and the parser yells when you try to execute the command.

Related Posts by Categories