Un certain nombre de choses peuvent être à l'origine de ce problème - malheureusement, nous avons besoin de plus d'informations.
Avant d'entrer dans le vif du sujet, une petite précision concernant vos pages HTML : en règle générale, le pool d'applications ne peut répondre qu'à un certain nombre de demandes à la fois. S'il est occupé à répondre aux demandes de pages dynamiques, il se peut qu'il ne reste plus de threads pour servir les pages statiques. C'est pourquoi un problème de code sur une page dynamique peut donner l'illusion que les pages statiques sont servies "lentement". Ce que je veux dire, c'est qu'il ne faut pas exclure le code ou le SQL.
A titre d'exemple : si vous avez 100 pages qui consultent une base de données ou une API en même temps, et que les 100 attendent une réponse, la demande 101 peut être bloquée jusqu'à ce qu'une des 100 premières soit complétée.
Maintenant il y a beaucoup de choses que vous pouvez faire pour vous aider à diagnostiquer ce problème :
-
Quel est votre profil de charge normalement ? Cela fait une grande différence - il se peut que vous siempre ont un problème, mais vous ne pouvez pas voir l'impact jusqu'à ce que votre site soit effectivement chargé. Vous pouvez essayer de tester cela (en phase de test) avec quelque chose comme JMeter.
-
Activez les journaux IIS (si ce n'est pas déjà fait). et les examiner pour voir quelles sont les demandes qui prennent le plus de temps. Vous pouvez utiliser quelque chose comme Analyseur de journaux (de Microsoft) pour exécuter des requêtes de type SQL sur vos journaux (ou même transférer vos journaux dans une base de données SQL), si cela vous facilite la vie. Une fois que vous savez quelles sont les pages qui prennent le plus de temps, vous pouvez leur consacrer une partie de votre attention.
-
Votre application dispose-t-elle de journaux ? Si ce n'est pas le cas, vous devriez envisager d'ajouter un système d'enregistrement. Si vous avez déjà des journaux, que disent-ils ? Votre application lève-t-elle des exceptions ? Y a-t-il quelque chose qui échoue systématiquement ?
-
Quelle quantité de mémoire votre pool d'applications utilise-t-il ? Une fuite de mémoire est un candidat évident, mais vous devriez être assez facile à voir. Utilisez la fonction intégrée de Windows Contrôleur de performance pour suivre la mémoire consommée par votre pool d'applications au cours de la journée, et voir si elle augmente au fil de la journée.
-
Comme je l'ai mentionné dans l'ouverture, Le SQL peut encore être un problème . Je vous recommande de jeter un coup d'œil au serveur de base de données, pour voir s'il n'y a pas de requêtes bloquées ou en cours d'exécution depuis longtemps (par exemple, dans le fichier sys.dm_exec_requests regardez le wait_type , wait_time , blocking_session_id y el total_elapsed_time ).
-
Vérifiez le nombre de connexions ouvertes dans votre pool d'applications en utilisant quelque chose comme TCPView (un autre outil de Microsoft). Votre pool d'applications essaiera de réutiliser les connexions dans la mesure du possible, mais vous verrez probablement un grand nombre de connexions ouvertes à votre pool d'applications. Une chose intéressante que vous pouvez voir est le nombre de connexions ouvertes à votre base de données SQL ou à toute API externe que votre application utilise.
-
Utilisez un outil de performance et de surveillance des applications. AppDynamics, ou un outil similaire, pourra vous aider à identifier les parties de votre code qui sont peu performantes. Malheureusement, il y a une petite courbe d'apprentissage pour être capable d'utiliser ces outils efficacement, mais ils peuvent être très puissants pour aider à diagnostiquer les problèmes de vos applications.
Mise à jour
Le redémarrage de votre pool d'applications peut aider à résoudre le problème si vous avez une fuite de mémoire, mais vous devez être prudent avec cela : il peut y avoir des impacts négatifs. Après avoir redémarré votre pool d'applications, votre application commencera à charger des objets statiques en mémoire, etc. Selon la complexité de votre application, cela peut prendre beaucoup de temps (5 à 10 minutes ou plus). Pendant ce temps, les requêtes adressées à votre serveur peuvent être retardées. apparaître que le problème est exacerbé.
Si vous utilisez un seul serveur, votre site peut devenir temporairement indisponible pendant que l'application redémarre (parce que le pool d'applications est occupé et ne peut pas répondre aux demandes). Si vous travaillez dans une ferme, avec un équilibreur de charge, ce dernier peut exclure votre serveur pendant le redémarrage du pool d'applications. podría diriger tout le trafic vers les autres serveurs et les surcharger. Ne redémarrez pas le pool d'applications sur tous vos serveurs en même temps, et essayez de "chauffer" les pools d'applications (en simulant des requêtes sur le serveur) avant de réintroduire des serveurs dans la ferme.
En d'autres termes : à moins qu'il ne s'agisse d'un problème de fuite de mémoire, il n'est peut-être pas utile de redémarrer le pool d'applications, car le problème peut réapparaître immédiatement.
Note : Le redémarrage du pool d'applications no d'avoir un impact sur les demandes en cours d'exécution. Celles-ci continueront à s'exécuter, à moins que vous ne fermiez de force le pool d'applications (par ex. Crtl + Alt + Del )
