J'ai une application Web ASP.NET (v4.0) installée dans un répertoire virtuel (en tant qu'application) et hébergée dans son propre pool d'applications. Ceci est répété pour chaque instance de l'application (c'est-à-dire par client).
Les pools d'applications sont intégrés en mode (non classique) et LoadUserProfile est défini sur true. Sinon, les paramètres par défaut.
Chaque instance possède actuellement sa propre copie du code / config et son propre dossier de données (lecture / écriture de fichier de base).
1 instance de cette application fonctionne bien (l'opération utilisée pour la comparaison prend environ 4 secondes). Toutes les autres instances s'exécutent lentement (de 10 à 25 secondes pour la même opération).
Si je déplace l'instance la plus lente vers le pool d'applications "le plus rapide", cette instance prend vie. Si je déplace l'instance la plus rapide dans le pool d'applications plus lent, cette instance ralentit vers une analyse.
Les pools d'applications ont été créés initialement de la même manière - manuellement. J'ai ensuite utilisé la routine de copie PowerShell pour garantir une copie exacte du pool d'applications plus rapide et toujours le même comportement. La comparaison des fichiers apppool.config montre qu'ils sont identiques sauf les affectations de répertoire virtuel.
Il n'y a pas de ressources partagées bloquées, pour autant que je sache, et j'ai testé cela en fermant le pool d'applications performant et en redémarrant ... lent est toujours lent, puis quand je redémarre ce pool d'applications (il est donc chargé enfin) c'est encore plus rapide ...
Réponses:
Pour isoler davantage le problème, je suggère d'exécuter Wireshark (ou un autre analyseur de paquets de choix) sur le système hôte, pendant deux sessions. L'hypothèse que je fais est que chaque pool d'applications a soit une adresse IP unique qui lui est attribuée, soit un port unique.
Obtenez d'abord vos performances de base en filtrant sur le port IP: de votre pool d'applications rapide. Découvrez à quoi ressemble le trafic à destination et en provenance de l'application dans des conditions "normales".
La deuxième exécution, vous devrez capturer le trafic à partir du pool d'applications lent / ne répond pas. Si tout le routage réseau et tel est correct jusqu'à la boîte, vous devriez voir des demandes répétées dans une direction, très probablement vers l'application d'ailleurs, MAIS si votre application est quelque chose qui fait beaucoup de demandes à un autre serveur, votre trafic peut être lourd sur la sortie au lieu de la pénétration.
Ce test vous dira si le problème est au sein de l'application, ou si ce sont des problèmes liés à TCP / IP qui entraînent une expiration du nombre de demandes à l'application en raison d'une communication faible ou inexistante.
Corrélez les horodatages de vos tests avec les journaux d'événements du serveur et (le cas échéant) les journaux de suivi de trace, et vous devriez pouvoir résoudre le problème.
la source
Le suivi des demandes ayant échoué (FRT) sera votre meilleur outil pour le retrouver. Il montrera le pipeline et le temps nécessaire pour terminer chaque étape. Cela devrait indiquer s'il s'agit de quelque chose dans la partie asp.net ou si c'est quelque chose dans le pipeline IIS lui-même.
Pour configurer FRT, à partir d'IIS au niveau du site, créez une règle FRT avec une plage d'état http de 200 à 999 et assurez-vous d'activer FRT (il s'agit d'une étape distincte du volet Actions).
Reproduisez ensuite le problème et examinez les fichiers générés (% SystemDrive% \ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}). Ouvrez-les dans Internet Explorer.
la source
Lorsque IIS retarde pendant de longues périodes sans raison apparente, cela signifie généralement qu'il attend qu'un service externe expire. Quand il le fait, il essaie une autre approche. C'est d'ailleurs le cas pour à peu près n'importe quoi sous Windows ou Linux. Le premier suspect pour moi dans ces situations est toujours la configuration de résolution de nom de réseau. Il est coupable jusqu'à preuve du contraire.
Est-ce que cela peut être recréé avec un utilisateur frappant l'un des sites en double? Il serait bon de savoir ce que font le processeur et les disques lorsque vous recréez le temps de réponse de 10 à 20 secondes. S'il apparaît que peu de choses se passent pendant les 10 à 20 secondes, vous devez vérifier vos noms de liaison et la résolution de noms pour les noms liés. Si le processeur ou les disques sont en train de ronger, vous devrez déterminer quel processus fonctionne trop dur et pourquoi.
Veuillez poster vos résultats, je suis curieux.
PS Je voudrais également vérifier la résolution des noms et l'accès à tous les services d'authentification qui peuvent être en jeu. Par exemple, si le serveur de domaine doit être consulté, assurez-vous que le premier serveur DNS de votre liste est le serveur DNS du domaine.
la source
Ce n'est pas la solution mais nous y travaillerons;
Exécutez IISRESET (pendant les heures de maintenance) ou supprimez le W3WP qui appartient au pool d'applications qui ne répond pas
Lancez l'application
Bien qu'il ne réponde pas, récupérez un fichier de vidage de W3WP qui appartient au pool d'applications lentes. Utilisez l' explorateur de processus ou le gestionnaire de tâches pour créer un fichier de vidage
Récupérez les fichiers mscordacwks.dll et mscorwks.dll sous C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX
Compressez et téléchargez ce fichier quelque part d'où je peux télécharger.
la source