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 ""
}

$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

0 comments:

Post a Comment