Commandes PowerShell pour vérifier et vérifier les meilleures pratiques de fonctionnement IIS/pools d'applications/ASP.NET
Dans tout effort d'amélioration, la première étape recommandée est d'explorer et de déterminer où en sommes-nous (explorer et analyser notre état actuel) en plus de savoir où aimerions-nous être, bien que chaque meilleure pratique puisse être confirmée et appliquée manuellement. , ce projet a été lancé dans un premier temps pour aider lors de la découverte. Comme premier résultat, nous aurons deux fichiers CSV, dans lesquels nous aurons les actions recommandées à couvrir et des informations générales sur le système actuel.
Ces commandes effectuent des opérations système en lecture seule, aucune action de modification n'est impliquée, les seules exceptions concernent deux fichiers csv créés uniquement pour contenir les résultats finaux.
Le temps de recyclage par défaut est de 1 740 minutes. Ensuite, un recyclage du pool d'applications aura lieu à un moment donné pendant les heures de bureau, ce qui pourrait entraîner une dégradation des performances et la fin des sessions utilisateur (le problème de fin de session utilisateur pourrait être atténué si ASP.NET conserve son état de session). out-proc, par exemple dans SqlServer), la valeur recommandée pour le recyclage du temps régulier est 0 (mise à zéro, cela signifie que le recyclage n'aura pas lieu en raison du temps écoulé), en plus de spécifier une heure spécifique, par exemple à 3h00
Le délai d'inactivité du recyclage par défaut est de 20 minutes, cela signifie qu'IIS arrêtera automatiquement un processus de travail après 20 minutes d'inactivité, puis lorsqu'une nouvelle requête arrive à l'application, le processus d'activation complet recommence (création d'un nouveau travailleur processus, pages ASP.NET et compilation de Dll, etc.), cela pourrait entraîner une dégradation des performances et la fin des sessions utilisateur, si l'utilisation de la mémoire du serveur nous le permet, alors, la valeur recommandée pour le délai d'inactivité est 0 (définie sur zéro, en en d'autres termes, IIS ne jamais arrêter un processus de travail déjà en cours en raison d'un temps d'inactivité, il ne sera recyclé que lorsque d'autres conditions de recyclage seront remplies)
L'identité par défaut utilisée par le processus de travail est ApplicationPoolIdentity, et elle dispose des privilèges requis pour exécuter presque toutes les applications Web. Au cas où ce compte devrait être modifié, nous devons nous assurer que le compte sélectionné n'a pas plus de privilèges que le minimum requis. , il n'est en aucun cas recommandé de quitter les comptes LocalService ou Administrateur pour exécuter un processus de travail en production, cela pourrait surexposer non seulement la sécurité des applications, mais également la sécurité de notre système d'exploitation.
Comme chaque pool d'applications démarre un processus de travail différent, il s'agit de la couche d'isolation ultime dans IIS. Ainsi, si pour une raison quelconque une application rencontre des problèmes de performances, des exceptions non gérées, des conflits de threads et/ou des problèmes de gestion des ressources, les autres applications ne devraient pas le faire. être affecté par ce mauvais comportement, et c'est vrai, mais uniquement lorsque chaque application est isolée dans son propre pool d'applications.
Ne laissez jamais accidentellement (ou délibérément) le commutateur
sur le fichier web.config de l'application, car cela entraînerait un certain nombre de problèmes non optimaux, notamment :
PS > build.ps1
, cela créera le dossier output
output
sur le serveur cible pour l'analyserPS > Run.ps1
HostName-Findings.csv
Contient tous les éléments d'action liés aux meilleures pratiques de fonctionnement IIS/ASP.NETHostName-BaseLineInfo.csv
Contient des informations générales sur l'état actuel du systèmeVous devez exécuter ces commandes en tant qu'administrateur
Toute amélioration du design est la bienvenue, toute nouvelle idée est également la bienvenue :)
Presque tout le code de Powerops a été conçu et écrit via TDD, je vous encourage donc à continuer avec cette bonne habitude
pour exécuter les tests unitaires, ouvrez un PowerShell en tant qu'administrateur et exécutez PS projectPath/test/> Invoke-Pester