Automatisierung vs. Performance

Seit dem Service Pack 1 für ConfigMgr gibt es ja Powershell CmdLets zur einfacheren Automatiserung vieler Vorgänge. Vor dieser Zeit blieb einem nur der Weg über WMI (vbs, Powershell usw).
Doch nicht alles, was einfach ist (und funktioniert), ist auch performant. In kleinen Umgebungen, oder Umgebungen, bei denen der Automatisierungsgrad nicht sehr hoch ist, fällt dies unter Umständen nicht einmal auf.
Schon kleine Tricks können dabei einen massiven Performance-Gewinn bringen. Hier ein Powershell-Beispiel zum Thema Performance. Gegeben ist der Name einer Collection (“Name_to_Search“). Diese soll in SCCM 2012 gefunden werden, um damit dann weiterarbeiten zu können.
Im Folgenden betrachte ich 4 unterschiedliche Möglichkeiten:

  1. Get-CMDeviceCollection | where {$_.Name -eq “Name_to_Search“}
  2. gwmi -Namespace root\sms\site_xyz -Class SMS_Collection | where {$_.Name -eq “Name_to_Search“}
  3. Get-CMDeviceCollection -Name “Name_to_Search
  4. gwmi -Namespace root\sms\site_xyz -Query “SELECT * FROM SMS_Collection where Name = ‘Name_to_Search

Hier jeweils die Dauer (gemessen mit measure-command) in Sekunden:

  1. 472
  2. 13
  3. 0,2
  4. 0,2

Man sieht, dass zwischen der kürzesten und längsten Laufzeit ein Faktor von ca. 2000 (!) liegt. Woran liegt das? Dazu sollte man sich betrachten, welche Abfragen (Queries) der SMS Provider jeweils ausführt:

  1. SELECT * FROM SMS_Collection WHERE CollectionType=2
    plus: GetObjectAsync : SMS_Collection.CollectionID=”XYZ00xxx” für alle CollectionIDs
  2. select * from SMS_Collection
  3. SELECT * FROM SMS_Collection WHERE Name=’Name_To-Search‘  AND CollectionType=2
  4. SELECT * FROM SMS_Collection where Name = ‘Name_to_Search

An den Beispielen 1) und 2) sieht man, dass erst alle Collection-Objekte verarbeitet werden müssen und man sich erst danach (mittels Pipe (|)) die wirklich benötigte herausfiltert.
Eine Analogie aus der Praxis dazu: man bestellt in einem Restaurant erst einmal alles von der Speisekarte, lässt alles von der Bedienung bringen, der Tisch wird richtig voll gestapelt und man sucht sich erst dann sein Gericht aus. Funktioniert. Aber eben nicht wirklich optimal, denn (a) wird dies teuer (man zahlt alle Gerichte, obwohl man nur eines isst) und (b) dauert dies lange (da die Bedienung zig mal hin- und herlaufen muß, um alles auszuliefern). Der Rest wird weggeworfen.
Die Methoden 3) und 4) sind deutlich schneller. Wieso? Weil man sich von Anfang an nur das aussucht, was man auch wirklich braucht. Am Beispiel des Restaurant-Besuches: man sucht sich das Gericht von der Speisekarte aus, welches man auch wirklich essen möchte. Entsprechend läuft die Bedienung nur einmal und man zahlt auch nur einmal.

Entsprechend gilt dies natürlich nicht nur für Collection, sondern auch alle anderen ConfigMgr-Objekte, die in großer Anzahl vorhanden sein können. Denkt also bei der Erstellung des nächsten Skripts kurz an das Beispiel von oben. Die Bedienung Der ConfigMgr-Provider und die Performance werden es euch danken!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert