PS Performance

Powershell ist das dafür berühmt, mit einem "Einzeiler" große Aufgaben zu lösen. Aber mit Powershell können auch ganz umfangreiche Programme entwickelt werden. Wenn Umgebungen aber größer werden, dann ist Performance mehr und mehr ein Thema. Es gibt je nach eingesetztem Befehl durchaus mächtige Unterschiede.

Measure-Command

Erster Schritt ist natürlich das "Messen" der Laufzeit. Dazu kann das Commandlet "Measure-Command" dienen, welches die Laufzeit eines Anweisungsblocks ermittelt. Allerdings führt das Commandlet den Block so erst mal nur "einmal" aus und zudem werden die Ausgaben des Codes an die Pipeline unterdrückt, was wieder Verfälschungen mit sich bringen kann. Für einfache Aufgaben ist es aber ausreichbar.

PS C:\> Measure-Command {Get-ChildItem}

Days  : 0
Hours : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 4
Ticks : 41882
TotalDays         : 4,8474537037037E-08
TotalHours        : 1,16338888888889E-06
TotalMinutes      : 6,98033333333333E-05
TotalSeconds      : 0,0041882
TotalMilliseconds : 4,1882

Der Befehlsblock in geschweiften Klammern kann auch durchaus mehrere Codezeilen enthalten. Allerdings ist der Code gekapselt, d.h. Ausgaben, die hier bei "Get-Childitem" natürlich vorhanden sind, gehen unter. Variable-Zuweisungen in dem Block sind aber auch außerhalb des Blocks verwendbar. Das folgende geht also schon

$laufzeit = measure-command { $recipientlist = get-recipient}
write-host "Laufzeit $laufzeit"
forach ($recipient in $recipientlist) {
    write-host "Recipient:"$recipient.identity
}

Wer damit misst, sollte die Befehle immer mehrfach aufrufen, denn die Laufzeit schwankt. Oft dauert gerade der erste Start länger und Folgeaufrufe sind zügiger. Sobald Abhängigkeiten mit anderen Diensten, z.B. LDAP-Abfragen, Webservices, im Spiel sind, müssen die Ergebnisse relativiert betrachtet werden.

Gerade auch kurze Befehle sollten über eine Schleife einfach mehrfach gestartet werden, z.B.

measure-command {
    1..100000 | %{
        get-date "01.01.1900"
    }
}

Wer mehr oder mehrere Punkte im Code messen möchte, kann dies mit GET-DATE tun, um die aktuelle Zeit sehr genau zu erhalten und von vorher ermittelten Werten abzuziehen.

• Measure-Command
  http://technet.microsoft.com/de-de/library/dd347702
• Using the Measure-Command Cmdlet
  http://technet.microsoft.com/en-us/library/ee176899.aspx
• Measuring Elapsed Time in Powershell
  http://poshtips.com/2010/03/30/measuring-elapsed-time-in-powershell/

Beispiele

Um die Auswirkungen anschaulich zu machen, habe ich drei Aufgaben heran gezogen, die das Potential aufzeigen sollen:

• Exchange Empfänger ermitteln
  Das ist sicher eine häufige Aufgabenstellung eine Liste von Empfängern nach Kriterien zu erstellen
• PSCustomObjekt als Ausgabe vorbereiten
  Oft erforderlich, wenn Sie als Rückgabe eine Liste mit Objekten erzeugen wollen, die wiederum Properties nutzt.
• Variable Zuweisen
  Am Ende noch ein ganz einfaches Beispiel für die Initialisierung von Variablen.
• Das "Count" Property
  Warum die einfache Anzeige der gefundenen Objekte Zeit kostet
• Debugausgaben mit Write-Host
  Wichtige Informationen bremsen extrem

Schauen wir uns die Ergebnisse im einzelnen an:

Beispiel 1: Exchange Empfängerabfrage / AD Abfrage

Ich denke für Exchange Administratoren ist die Abfrage der Exchange Empfänger ein häufiger Prozess, der auf mehrere Wege durchgeführt werden kann.

• Get-Recipient
  Dieses Exchange Commandlet nutzt die Exchange Remote Powershell um Exchange Empfänger zu ermitteln. Es ist sehr leistungsfähig und liefert nett bereitgestellte Objekte als Rückgabe.
• Get-ADObject
  Etwas einfacher ist Get-ADObject aus dem Windows 2008 Powershell Modul "ActiveDirectory". Es macht aber auch keine direkten LDAP-Abfragen, sondern nutzt die ADWS-Dienste eines Windows 2008 DCs oder höher.
• [ADSI]
  Der gute alte ADSI-Zugriff von Powershell geht direkt per LDAP an die Server. Das Ergebnis sind "Rohdaten" ohne weitere Unterstützung, durch den LDAP-Zugriff ist dieser Weg nicht nutzbar, wenn Office 365 im Spiel ist und eine Verarbeitung über die Pipeline ist uneffektiv, da ein "Findall()" immer erst alle Daten sucht ehe es weiter geht. Dafür funktioniert dies auch ohne Exchange Module auf dem PC
• LDIFDE/CSVDE
  Außer Konkurrenz laufen diese beide Programme, die ich in DirSync-Projekten oft verwende. Anscheinend haben die Entwickler dieser Programme ziemlich viel optimiert, denn ein Export per CSVDE ist fast immer noch um einiges schneller als alle der drei vorherigen Optionen. Ich denke das sind dann die Einschränkungen eines interpretierten Skripts

Ich habe alle drei Optionen einmal gegeneinander gestellt, um die Performance in einer etwas größeren Umgebung zu demonstrieren. Das Beispiel fragt ca. 30.000 Einträge ab. Um die Ausgabe der Objekte zu ersparen, wird einfach nur die Anzahl der Objekte zurück gegeben. Dennoch sind die Zeiten natürlich nur eine Momentaufnahme meiner Umgebung. Aber es ist offensichtlich, das "höherwertigen" Commandlets und speziell die Exchange remote Powershell deutlich langsamer. Insofern muss man speziell für aufwändige Auswertungen mit vielen Empfängern überlegen, ob bei der Suche schon gefiltert oder ein schnellerer Weg genutzt wird.

Die Dauer gibt eine Momentaufnahme meiner VMs wieder und ist nicht repräsentativ. Es gibt Varianten bei denen die Initialisierung länger dauert aber beim Zugriff dann schneller sind während andere sofort aber dann nicht so schnell Daten liefern. Auch kann über die Pagesize ein Tuning erfolgen.

measure-command { `
    write-host "total:"(get-recipient -resultsize unlimited).count
}

measure-command { `
    write-host "total:"(get-adobject `
   -ldapfilter "(mailnickname=*)" `
   -ResultSetSize $null `
   -server "server:3268").count 
}

measure-command {
   $root = [system.directoryservices.activedirectory.forest]::getcurrentforest().rootdomain.name
   $adsearch= New-Object System.DirectoryServices.DirectorySearcher([ADSI]"GC://$root")
   $adsearch.Propertiestoload.add("distinguishedname") | out-null
   $adsearch.Propertiestoload.add("mail") | out-null
   $adsearch.Propertiestoload.add("ProxyAddresses") | out-null
   $adsearch.pagesize = 100
   $adsearch.filter = "(mailnickname=*)"
   $adsearch.filter = "(objectclass=*)"
   $adresult =$adsearch.findall()
   write-host $adresult.count
}

# Ausgabe dann per FOR-Schleife
ForEach ($strResult In $adresult) {
    $strDN = $strResult.Properties.Item("distinguishedName")
    Write-Host "DN:"$strDN
}

measure-command {
    $adoConnection = New-Object -comObject "ADODB.Connection"
    $adoConnection.Open("Provider=ADsDSOObject;")
    $adoCommand = New-Object -comObject "ADODB.Command"
    $adoCommand.ActiveConnection = $adoConnection
    $adoCommand.Properties.Item("Page Size") = 100
    $adoCommand.Properties.Item("Timeout") = 30
    $adoCommand.Properties.Item("Cache Results") = $False

    $root = [system.directoryservices.activedirectory.forest]::getcurrentforest().rootdomain.name
    $strbase="<GC://$root>"
    $strFilter = "(mail=*)"
    $strAttributes = "distinguishedName,mail,proxyaddresses"
    $strScope = "subtree"
    $strQuery = "$strbase;$strFilter;$strAttributes;$strScope"

    $adoCommand.CommandText = $strQuery
    $adoRecordset = $adoCommand.Execute()
    write-host "Items Found:"$adoRecordset.recordcount
}

# Ausgabe hier dann mit FindFirst ud FindNext
Do {
    $adoRecordset.Fields.Item("distinguishedName") | Select-Object Value
    $adoRecordset.MoveNext()
} Until ($adoRecordset.EOF)
$adoRecordset.Close()
$adoConnection.Close()

measure-command {
    CSVDE -f Benutzer.csv -r "(mailnickname=*)" -l "mail,proxyaddresses" -s msxfaq.net -t 3268
}

Allerdings muss man hier natürlich zugeben, dass die Exchange Powershell für den Get-Recipient einige Fehler mehr aus dem AD auslesen muss, um das Ausgabeobjekte zu befüllen. Beim ADSI-Query kann ich genau angeben, welche Felder ich benötige und damit natürlich Zeit sparen.

Beispiel 2: Variablen zuweisen

Diese Aufgabe ist eine kleine Vorarbeit für Beispiel 3. Stellen Sie sic vor ich initialisiere eine Datenstruktur und habe mehrere Felder um ein Datum zu speichern. Um später zu erkennen, welche Felder gar nicht beschrieben wurden, wird ein Startdatum weit in der Vergangenheit gesetzt. So funktionieren "Vergleiche" weiterhin. Stellen sie sich nun vor, Sie müssen eine umfangreiche Liste mit vielen Objekten aufbauen und alle Datumfelder so setzen. Dann ist das schon ein Zeitfaktor. Also starten wir mit der Generierung eines Datums, welches drei Variablen füllt:

Es kann also auch in Powershell sinnvoll sein, eine Start-Wert, der häufiger verwendet wird, schon vorzubereiten.

Beispiel 3: Objekte für Listenaufbau belegen

Viele meiner Skipte erstellen Berichte und Ausgaben, die im Code schon als CSV-Datei exportiert werden sollen. Diese Ergebnisse eines Datensatzes speichert man natürlich nicht in vielen einzelnen Variablen, sondern fasst diese als "PSCustomObjekt" zusammen. Bei der Initialisierung muss man natürlich darauf achten, dass jedes Ergebnis wieder mit einem neu initialisierten Objekt anfängt. Ein "$obj1=$obj2" ist bei PSCustomObjekts schlecht, da dabei nicht das Objekt kopiert wird, sondern nur eine Referenz erstellt wird. Ändert man dann $obj1, dann ändert sich auch $obj2. Folgendes Beispiel verdeutlicht das.

Das wirkt sogar noch nach, wenn das Objekt genutzt wird, um es in ein Dictionary oder eine Arrayliste zu addieren. Also muss ich das Objekt neu aufbauen, oder einen "Clone" erstellen. Leider kann man PSCustomObjects nicht einfach Clonen, so dass ich es einfach neu aufbaue. Und dazu gibt es drei Optionen.

measure-command {
   1..10000 | %{	
    $newpso =new-object psObject
    $newpso | Add-Member -MemberType noteproperty -Name "mailaddress" -Value "notset"
    $newpso | Add-Member -MemberType noteproperty -Name "PrimarySmtpAddress" -Value "notset"
    $newpso | Add-Member -MemberType noteproperty -Name "TotalItem" -Value 0
    $newpso | Add-Member -MemberType noteproperty -Name "date1" -Value (get-date 01.01.1900)
    $newpso | Add-Member -MemberType noteproperty -Name "date2" -Value (get-date 01.01.1900)
    $newpso | Add-Member -MemberType noteproperty -Name "date3" -Value (get-date 01.01.1900)
   }
}

Measure-Command {
   1..10000 | %{
      $newpso = New-Object PSObject -Property @{
         mailaddress = "NotSet"
         PrimarySmtpAddress = "NotSet"
         totalItem = 0
         date1 = (Get-Date 01.01.1900)
         date2 = (Get-Date 01.01.1900)
         date3 = (Get-Date 01.01.1900)
      }
   }
}

measure-command {
   1..10000 | %{
      $newpso = ("" | select mailaddress,PrimarySmtpAddress,TotalItem,Date1,date2,date3)
      $newpso.mailaddress="NotSet"
      $newpso.PrimarySmtpAddress="NotSet"
      $newpso.totalItem=0
      $newpso.date1=(get-date 01.01.1900)
      $newpso.date2=(get-date 01.01.1900)
      $newpso.date3=(get-date 01.01.1900)
   }
}

Add-Type @"
    namespace Test {
        public class MyObject {
            public string mailaddress;
            public string PrimarySmtpAddress;
            public int totalItem;
            public System.DateTime date1;
            public System.DateTime date2;
            public System.DateTime date3;
        }
    }
"@

(Measure-Command {
   1..10000 | %{
    $newpso5 = New-Object Test.MyObject
    $newpso5.mailaddress="NotSet"
    $newpso5.PrimarySmtpAddress="NotSet"
    $newpso5.totalItem=0
    $newpso5.date1=(Get-Date 01.01.1900)
    $newpso5.date2=(Get-Date 01.01.1900)
    $newpso5.date3=(Get-Date 01.01.1900)
   }
}).TotalSeconds

Es ist gut zu sehen, dass der Trick mit dem "select" deutlich schneller ist als der klassische Ansatz oder der Versuch ein Objekt zu kopieren. Beim klassischen Ansatz kostet es einfach zu viel Zeit immer wieder "Add-Member" aufzurufen.

Beispiel 4: Das "Count-Property"

Es ist so schön einfach, wenn ein Skript per ADO eine Datenbankabfrage oder per ADSI eine Suche im Active Directory durchgeführt hat und voller Stoltz ist das erste, was ein Programmierer als nächste Zeile einbaut ein

write-host "Gefundene Elemente:" $resultset.count

Unschön dabei ist, dass sowohl ADO als auch ADSI erst dann einen "Count" zurück geben können, wenn Sie die ganzen Daten einmal ausgelesen haben. Sie verlieren also kostbare Zeit. Wenn die Anzahl der Ergebnisse im Skript nicht für etwas anderes erforderlich ist, z.B. eine Fortschrittsanzeige auszugeben oder die Gültigkeit der Rückgabe zu prüfen, dann kann man das einfach sein lassen und direkt zur Verarbeitung der Ergebnisse übergehen.

Es spricht ja nichts dagegen bei der Verarbeitung einige nützlichere Counter mit hochzuzählen und auszugeben.

Beispiel 5: "Write-host" und Start-Transcript

Zugegeben ich schreibe viele Skripte und natürlich möchte ich wissen, was die Skripte genau tun. Ich kann ja nicht jedes Skript permanent im Debugger laufen lassen. Also machte ich, was auch viele andere Administratoren, Consultants und Entwickler machen: Sie schreiben "Debugausgaben" in das Script. Und nichts ist einfacher als ein "Write-Host" und wenn ich das auch mit protokollieren will, dann addiere ich noch ein Start-Transcript am Anfang.

Aber genau die Ausgaben auf dem Bildschirm machen die Skripte langsam, da die Ausgabe auf dem Bildschirm gescrollt werden muss etc. Nicht umsonst habe ich mir eine eigene Routine gebaut, die "Write-Host" ersetzt und die Ausgaben direkt in eine Datei umlenkt und einige Mehrwertfunktionen bietet. (Siehe MSXFAQLogger).

Kleiner Tipp: Wenn Sie viele Daten verarbeiten und einen Statusupdate erhalten wollen ohne dass der Bildschirm allzu viel scrollt, dann zeigen Sie doch den Fortschritt mit einer nummer auf, die nur all 100 oder 1000 Änderungen aktualisiert wird.

if (!($count%1000)) {write-host "`rUsers:"$count -nonewline}

Write-Host ist also nicht das schnellste Modul, aber geht es schneller ?. Ja, z.B. über [console]

measure-command {
   1..100000 | %{
      write-host "hallo"
   }
}

measure-command {
   1..100000 | %{
      [console]::Write("hallo`n")
   }
}

$start=get-date
   1..100000 | %{
      "hallo"
   }
write-host "dauer" ((get-date)-$start).totalseconds

measure-command {
   1..1000 | %{
      if (!($_ % 100)) {write-host $_}
      "hallo" | out-file .\debug.txt -append
   }
}

measure-command {
   Trap {"Error: $_"; $result | out-file .\debug.txt ;Break;}
   $result=@()  # oder [string]$result=""
   1..100000 | %{
      if (!($_ % 100)) {write-host $_}
      $result+="hallo"
   }
   $result | out-file .\debug.txt
}

measure-command {
   $debugfile = New-Object System.IO.StreamWriter "c:\temp\debug.txt"
   1..100000 | %{
      if (!($_ % 100)) {write-host $_}
      $debugfile.WriteLine("hallo")
   }
   $debugfile.Close();
}

Der StreamWriter ist also bezüglich "schreiben" durch nichts zu übertreffen und damit die erste Wahl, um Debugfiles wegzuschreiben. Sie sehen schon die Laufzeitunterschiede einer einfachen Ausgabe.

• StreamWriter-Klasse
  http://msdn.microsoft.com/de-de/library/system.io.streamwriter(v=vs.80).aspx
• Add-Content and Out-File are not for performance
  http://sqlblog.com/blogs/linchi_shea/archive/2010/01/04/add-content-and-out-file-are-not-for-performance.aspx

Beispiel 6: Listen erweitern

Natürlich lebt Powershell auch von der Pipeline. Aber manchmal möchte ich die Ergebnisse doch erst in einer Liste sammeln und danach weiter verarbeiten oder z.B. mit Export-CSV innerhalb des Programms in eine Datei exportieren. Also nehme ich die Werte und "addiere" diese. Am Beispiel mit String könnte das so aussehen:

[String]$ergebnis = ""

foreach ($repeat in 0..9) {
    $start = get-date
    foreach ($zeile in 0..999) {
        $ergebnis += "Zeile $repeat $zeile"
    }
write-host "Repeat $repeat  Dauer: "((get-date) - $start).totalseconds
}

Ausgabe:
Repeat:0  Dauer:  0,0210012
Repeat:1  Dauer:  0,0150009
Repeat:2  Dauer:  0,0220013
Repeat:3  Dauer:  0,053003
Repeat:4  Dauer:  0,297017
Repeat:5  Dauer:  0,3610207
Repeat:6  Dauer:  0,5040289
Repeat:7  Dauer:  0,5900338
Repeat:8  Dauer:  0,6060346
Repeat:9  Dauer:  0,6610378

Ich habe noch nicht hinter die Kulissen geschaut aber anscheinend kopiert Powershell (oder .NET) intern die Variable beim Erweitern um statt dynamische mit Pointern zu arbeiten. Es ist also vielleicht nicht die beste Idee, so eine Liste aufzubauen. Das gilt insbesondere, wenn sie ganz große Strukturen über Strings aufbauen wollen.

Deutlich besser schlagen sich Hashtabellen:

[hashtable]$ergebnis = @{}
foreach ($repeat in 0..9) {
	$start = get-date
	foreach ($zeile in 0..999) {
		$ergebnis.add( ([string]$repeat+[string]$zeile),"Zeile $repeat $zeile")
	}
	write-host "Repeat:$repeat  Dauer: "((get-date) - $start).totalseconds
}

Repeat:0  Dauer:  0,0370021
Repeat:1  Dauer:  0,0130008
Repeat:2  Dauer:  0,0100006
Repeat:3  Dauer:  0,0100005
Repeat:4  Dauer:  0,0150008
Repeat:5  Dauer:  0,0090005
Repeat:6  Dauer:  0,0090005
Repeat:7  Dauer:  0,0130007
Repeat:8  Dauer:  0,0100006
Repeat:9  Dauer:  0,0120007

Im Gegensatz dazu schlagen sich Arrays sogar noch schlechter:

[Array]$ergebnis = @()
foreach ($repeat in 0..9) {
	$start = get-date
	foreach ($zeile in 0..999) {
		$ergebnis += "Zeile $repeat $zeile"
	}
	write-host "Repeat:$repeat  Dauer: "((get-date) - $start).totalseconds
}

Repeat:0  Dauer:  0,0740042
Repeat:1  Dauer:  0,1830105
Repeat:2  Dauer:  0,2580147
Repeat:3  Dauer:  0,3360192
Repeat:4  Dauer:  0,4260243
Repeat:5  Dauer:  0,52503
Repeat:6  Dauer:  0,6060346
Repeat:7  Dauer:  0,70004
Repeat:8  Dauer:  0,8160467
Repeat:9  Dauer:  1,1250643

Weitere Variablen habe ich aber nicht untersucht

Haben Sie eine bessere Idee für ein Aufbau einfacher Listen ?

Beispiel 7: Funktionen einbinden

Aus Gründen der Modularisierung und Wiederverwendung von Code bietet es sich an, geeignete Codeabschnitte als Funktion in eigene PS1-Dateien oder PS1M-Module auszulagern und im Hauptskript dann einzubinden. Auch dazu gibt es unterschiedliche Ansätze, die sich auf die Performance niederschlagen können.

Achtung:
Die Beispiele hier zeigen rein den Overhead der jeweiligen Einbindung. Da der Code aber nicht "aktiv tut", sind die Zahlen viel drastischer aber dennoch nicht zu unterschätzen.

Das Muster besteht aus einem MAIN-Skript, welches in zwei Fällen auf eine ausgelagerte Funktion in einem SUP.PS1 zurück greift.

$sum=0
foreach ($item in 1..1000) {
$sum += $item 
}write-host "Main End sum: $sum"

 
$sum=0
foreach ($item in 1..1000) {
$sum += . .\sub.ps1  #
}write-host "Main End sum: $sum"

$item

function add-item {
                $item
}
 
$sum=0
foreach ($item in 1..1000) {
$sum += add-item
}write-host "Main End sum: $sum"

. .\sub.ps1   # einbinden
$sum=0
foreach ($item in 1..1000) {
$sum += add-item
}
write-host "Main End sum: $sum"

#sub.ps1
function add-item {
                $item
}

Interessant ist schon, dass allein die Auslagerung in eine Funktion innerhalb der gleichen PS1-Datei schon die Ausführung derart verlangsamt. Wird aber die Funktion in jeder Schleife neu aus einer anderen PS1-Datei bezogen, dann leidet die Performance stark. Bindet man die Funktion aber vorher über DOT-Sourcing mit ein, dann ist man nicht schlechter dran, als wenn man die Funktion im gleichen Skript definiert.

Beispiel 8: Textdateien lesen

Textdateien sind eigentlich was schönes, da man sie einfach lesen und schreiben kann und in fast jedem Editor auch anzeigen und bearbeiten kann. Zugegeben kommt Notepad auch unter Windows 8 mit großen Dateien immer noch an seine Grenzen, so dass man gut beraten ist, alternative Editoren (z.B. Notepad++, Textpad) zu verwenden oder gleich die Informationen per Skript zu extrahieren. So bin also auch ich immer mal genötigt, Textdateien schnell zu parsen und mittlerweile ist natürlich Powershell mein Mittel der Wahl. Als ich aber einmal ein 50 Megabyte großes Lync Client Tracefile parsen wollte, ist mir die Langsamkeit aufgefallen und das wollte ich nicht ganz wahr haben. Daraufhin habe ich eine kleine Mess-Serie aufgestellt, wie man eine große Textdatei am besten zeilenweise schnell einliest. Powershell eröffnet dabei doch einige Optionen. Alle Befehle verwendeten die gleiche Powershell und ich habe die Befehle immer zweimal gestartet, um etwaige Verfälschungen durch Caching zu eliminieren. Es kann also sein, dass die Zeiten "zu gut" sind, weil Daten noch in einem Cache gelegen haben. Virenscanner war aktiv aber es war mein Notebook. Hyperschnelle Raid-Controller mit eigenen Caches gibt es also nicht. Die Zeiten wurden mit Measure-command gemessen.

Wenn ich mir das so anschaue, dann ist es schon erschreckend, wie langsam der ein oder andere Code ist. Ich kann aber nicht genau verstehen, warum z.B. "Type" so viel schneller sein soll, so es doch auch nur ein "alias" für "Get-Content" ist. 

• Optimizing Performance of Get-Content for Large Files
  http://rkeithhill.wordpress.com/2007/06/17/optimizing-performance-of-get-content-for-large-files/

Weitere Themen

Und das waren nun nur ein paar Beispiele. Es gibt noch weitere Themen, die knifflig sein können, z.B.:

• Eventlog
  Es macht sehr wohl einen Unterschied, ob sie mit "Get-WinEvent" oder "Get-Eventlog" arbeiten
• Dateizugriffe
  Wer mit "out-File" oder "out-csv" arbeitet, nutzt den einfachen aber sicher nicht den schnellsten Weg. StreamWriter sind für große Dateien eine ebenso einfache aber viel schnellere Alternative
• Filtern
  Viele Exchange Commandlets erlauben die Angabe eines Filters. Wenn Sie nur eine Teilmenge benötigen, sollten Sie nicht erst alle Elemente holen und mit einem "WHERE" die Ausgabe filtern, sondern vorher schon einen Filter bei der Abfrage hinterlegen. Leider lassen sich bei Exchange nicht alle Properties mit OPATH filtern.
• Suchen und Vergleichen
  Gerade beim Abgleich von Daten muss man überlegen, ob man jede Information in der Quelle im Ziel "sucht" oder ob es nicht vielleicht schneller geht, die Daten des Ziels flugs in eine Hashtable einzulesen und dort dann "im Memory" zu suchen. Das ist insbesondere bei AD-Abfragen oft deutlich schneller anstatt den DC mit massenhaft Anfragen zu belästigen.

Insofern kann es sich schon mal lohnen zu schauen, wo ein Code seine Zeit verbringt.

Zusammenfassung

Auch wenn Powershell relative einfach ist und passende Commandlets gerade im Bereich Exchange einen Zugriff auf Objekte deutlich unterstützen, so muss zumindest in größeren Umgebungen geprüft werden, ob die einfachen aber ressourcenintensiven Commandlets die Anforderungen an die Laufzeit erfüllen. Ich merke dies immer in Umgebungen, wo ich mit Powershell Skripte zur Auswertung erstelle. Wenn Sie z.B. per Powershell die Adressbücher von zwei Mailsystemen auslesen, um diese dann zu "vergleichen", dann ist es nicht lustig, wenn eine Auswertung 10 Minuten und länger läuft.

Weitere Links

• Measure-Command
  http://technet.microsoft.com/de-de/library/dd347702
• Using the Measure-Command Cmdlet
  http://technet.microsoft.com/en-us/library/ee176899.aspx
• Powershell and writing files (how fast can you write to a file? )
  http://blogs.technet.com/b/gbordier/archive/2009/05/05/powershell-and-writing-files-how-fast-can-you-write-to-a-file.aspx
• Measuring Elapsed Time in Powershell
  http://poshtips.com/2010/03/30/measuring-elapsed-time-in-powershell/
• PowerShell: Get-WinEvent vs. Get-EventLog
  http://www.mcbsys.com/techblog/2011/04/powershell-get-winevent-vs-get-eventlog/
• How to Improve the Performance of a PowerShell Event Log Query
  http://blogs.technet.com/b/heyscriptingguy/archive/2011/03/08/how-to-improve-the-performance-of-a-powershell-event-log-query.aspx
• Performance with PowerShell
  http://tfl09.blogspot.de/2011/11/performance-with-powershell.html

• NOTFALL
• Grundlagen
• Konzepte
• Signieren und Verschlüsseln
• Verfügbarkeit
• Admin und Betrieb
• Ex 2000/2003
• Ex 2007/2010
• Ex 2013
• Unified Communication
• Lync/UC
• Mobile Clients
• Clients
• Connectoren
• Internet
• Spam und UCE
• Migration/Koexistenz
• Office 365
• Tools
• How-To
• Programmieren
  • Wege zu Exchange
  • Powershell
    • PS Beispiele
    • PS Variablen
    • PS Pipeline
    • PS CSV-Datei
    • PS DataTable
    • PS Debugging
    • PS Eventlog
    • PS Perfmon
    • PS Klassen
    • PS Module
    • PS Remote
    • PS Parallel
    • PS Performance
    • PSSnapin mit VS
    • Powershell3
  • Formulare
  • Outlook VBA
  • Outlook AddIns
  • Outlook VBScript
  • Messageclass
  • MAPI/CDO
  • WebDAV
  • Webservice
  • EWS
  • Event Service
  • ExOLEDB
  • Eventsinks
  • SMTP-EventSink
  • E200x Storesink
  • SingleServerSink
  • Transportagenten
  • CmdLetExtensionAgent
  • Schema Version
  • ByVAL/ByRef
  • RegEx
  • Office WebCharts
  • TokenGroup
  • Dirsync-API
  • FileSystemTunnel
  • Outlook Security
  • ADSI und LDAP
  • RSAT AD-Powershell
  • LDAP 5.5
  • Kontaktfelder
  • VBScript
  • Entwicklungskosten
  • .Net Framework
  • .NET für Admins
  • ASP
  • ASP.NET
  • ASP.NET Sitemap DE
  • ASP.NET Sitemap EN
  • XML
  • WMI
  • Redemption
  • VBSToolbox
  • Note2MAIL
  • SCL-Skript
  • MakeUser
  • MakeContact
  • EventlogMon
  • Send Mail
  • AddContact
  • CheckOWA
  • Rights
  • ADREAD
  • Pickup
  • MBSize
  • SMTPList
• Produkte
• Events
• Buch
• Verschiedenes
• Ideen
• Sonstiges
• Net at Work
• Newsletter
• Archiv
• English pages