PowerShell-Befehle zum Überprüfen und Verifizieren der Best Practices für den Betrieb von IIS/Anwendungspools/ASP.NET
Bei jeder Verbesserungsbemühung besteht der erste empfohlene Schritt darin, herauszufinden, wo wir stehen (unseren aktuellen Zustand zu erkunden und zu analysieren) und herauszufinden, wo wir gerne wären, obwohl jede Best Practice manuell bestätigt und angewendet werden könnte Dieses Projekt wurde zunächst gestartet, um bei der Entdeckung zu helfen. Als erste Ausgabe erhalten wir zwei CSV-Dateien, in denen wir die empfohlenen Aktionspunkte und allgemeine Informationen über das aktuelle System enthalten.
Diese Befehle führen schreibgeschützte Systemoperationen aus, es sind keine Änderungsaktionen erforderlich, die einzigen Ausnahmen sind zwei CSV-Dateien, die nur erstellt werden, um die Endergebnisse zu enthalten.
Die standardmäßige Recyclingzeit beträgt 1740 Minuten. Dann findet zu einem bestimmten Zeitpunkt während der Geschäftszeiten ein App-Pool-Recycling statt. Dies kann zu Leistungseinbußen und beendeten Benutzersitzungen führen (das Problem mit beendeten Benutzersitzungen könnte gemildert werden, wenn ASP.NET seinen Sitzungsstatus beibehält). out-proc, zum Beispiel in SqlServer), ist der empfohlene Wert für die regelmäßige Wiederverwendungszeit 0 (auf Null gesetzt, bedeutet dies, dass die Wiederverwendung aufgrund der verstrichenen Zeit nicht erfolgt), zusätzlich zur Angabe einer bestimmten Zeit, beispielsweise um 3:00 Uhr
Das Standard-Recycling-Leerlauf-Timeout beträgt 20 Minuten. Dies bedeutet, dass IIS einen Arbeitsprozess nach 20 Minuten Inaktivität automatisch herunterfährt. Wenn dann eine neue Anforderung bei der Anwendung eintrifft, beginnt der vollständige Aktivierungsprozess erneut (Erstellung eines neuen Arbeitsprozesses). Prozess, ASP.NET-Seiten und DLLs-Kompilierung usw.), kann dies zu Leistungseinbußen und beendeten Benutzersitzungen führen. Wenn die Speichernutzung des Servers dies zulässt, ist der empfohlene Wert für das Leerlauf-Timeout 0 (auf Null gesetzt, in andere worte, IIS wird einen bereits laufenden Arbeitsprozess niemals aufgrund von Inaktivitätszeit herunterfahren, er wird nur recycelt, wenn andere Recyclingbedingungen erfüllt sind)
Die vom Arbeitsprozess verwendete Standardidentität ist ApplicationPoolIdentity und verfügt über die erforderlichen Berechtigungen zum Ausführen nahezu jeder Webanwendung. Falls dieses Konto geändert werden muss, müssen wir sicherstellen, dass das ausgewählte Konto nicht über mehr Berechtigungen als das erforderliche Minimum verfügt Es wird niemals und unter keinen Umständen empfohlen, LocalService- oder Administratorkonten zu belassen, um den Arbeitsprozess in der Produktion auszuführen. Dies könnte nicht nur die Anwendungssicherheit, sondern auch die Sicherheit des Betriebssystems übermäßig gefährden
Da jeder Anwendungspool einen anderen Arbeitsprozess startet, ist dies die ultimative Isolationsschicht in IIS. Wenn also aus irgendeinem Grund eine Anwendung Leistungsprobleme, nicht behandelte Ausnahmen, Threadkonflikte und/oder Probleme mit der Ressourcenverwaltung hat, sollte dies bei anderen Anwendungen nicht der Fall sein von diesem schlechten Verhalten betroffen sein, und das stimmt, aber nur, wenn jede Anwendung in ihrem eigenen Anwendungspool isoliert ist.
Belassen Sie niemals versehentlich (oder absichtlich) den Schalter
in der web.config-Datei der Anwendung, da dies zu einer Reihe nicht optimaler Ereignisse führen kann, darunter:
PS > build.ps1
, dadurch wird der output
erstelltoutput
zur Analyse auf den ZielserverPS > Run.ps1
HostName-Findings.csv
Enthält alle Aktionselemente im Zusammenhang mit den Best Practices für den IIS/ASP.NET-BetriebHostName-BaseLineInfo.csv
Enthält allgemeine Informationen über den aktuellen Zustand des SystemsSie müssen diese Befehle als Administrator ausführen
Jede Designverbesserung ist willkommen, jede neue Idee ist ebenfalls willkommen :)
Fast der gesamte Code in Powerops wurde über TDD entworfen und geschrieben, daher empfehle ich Ihnen, diese gute Angewohnheit beizubehalten
Um die Komponententests auszuführen, öffnen Sie eine Powershell als Administrator und führen Sie PS projectPath/test/> Invoke-Pester
aus