Question Le temps de réponse ralentit au fur et à mesure que la journée avance, par où commencer le dépannage?


Mes informaticiens ne font que hausser les épaules lorsque je soulève la question. Je me tourne donc vers SE pour obtenir de l'aide.

Je pense que cette image le montre mieux.

graph of http performance

Tout simplement, à mesure que la journée avance, le temps de réponse ne cesse de s’aggraver, jusqu’à ce que vers minuit, il se passe quelque chose qui retombe presque à la normale. Nous sommes sur IIS, cette page se trouve toujours dans ASP classique, mais cela se produit sur toutes les pages, même les pages HTML simples, ce qui, à mon avis, élimine un problème de connectivité SQL.

Je suppose que ma question est la suivante: où puis-je commencer à chercher? J'ai parcouru les journaux réguliers et je n'ai rien vu qui me saute aux yeux. Mais il se passe évidemment quelque chose et je ne sais pas par où commencer.


6
2018-03-19 20:24


origine


Je me souviens d'avoir lu une entrée DailtWTF similaire à celle-ci. Il s'est avéré que le serveur redémarrait toutes les nuits. Je vais essayer de trouver l'entrée. - JMK


Réponses:


Cela pourrait être causé par un certain nombre de facteurs. Malheureusement, nous avons probablement besoin d'un peu plus d'informations.

Avant de commencer, permettez-moi de revenir rapidement sur 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 en train de répondre à des demandes de pages dynamiques, il ne reste alors aucun fil pour servir les pages statiques. Pour cette raison, un problème de code sur une page dynamique peut donner l’illusion que les pages statiques sont servies "lentement". Mon point est, n'excluez pas le code ou SQL.

Par exemple: Si vous avez 100 pages frappant toutes une base de données ou une API en même temps et que toutes les 100 attendent une réponse, la demande 101 peut être bloquée jusqu'à ce que l'une des 100 premières soit terminée.

À présent, il y a beaucoup de choses que vous pouvez faire pour vous aider à diagnostiquer ce problème:

  • À quoi ressemble votre profil de charge normalement? Cela fait une grande différence - il se peut que vous toujours vous avez un problème, mais vous ne pouvez pas en voir l’impact tant que votre site n’est pas réellement chargé. Vous pouvez essayer de tester cela (dans la mise en scène) avec quelque chose comme JMeter.

  • Activer les journaux IIS (si vous ne l'avez pas déjà fait), puis les regarder pour voir quelles demandes prennent le plus longtemps. 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 vider vos journaux dans une base de données SQL), si cela vous simplifie la vie. Une fois que vous savez quelles pages prennent le plus de temps, vous pouvez concentrer votre attention sur elles.

  • Votre application a-t-elle des journaux? Si ce n'est pas le cas, vous devriez envisager d'ajouter une certaine journalisation. Si vous avez déjà des journaux, que disent-ils? Votre application génère-t-elle des exceptions? Y a-t-il quelque chose qui échoue constamment?

  • Combien 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. Utiliser Windows intégré Moniteur de performances 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, SQL peut encore être un problème. Je vous recommande d’examiner le serveur de base de données pour savoir s’il existe des requêtes bloquées ou de longue durée (par exemple, dans sys.dm_exec_requests, regarde le wait_type, wait_time, blocking_session_id et le total_elapsed_time).

  • Vérifiez le nombre de connexions ouvertes dans votre pool d'applications., en utilisant quelque chose comme TCPView (un autre outil Microsoft). Votre pool d'applications tentera de réutiliser les connexions dans la mesure du possible, mais vous verrez probablement beaucoup de connexions ouvertes dans votre pool d'applications. Une chose intéressante que vous pouvez constater à partir de cela est maintenant le nombre de connexions que vous avez ouvertes avec votre base de données SQL ou toute API externe utilisée par votre application.

  • Utilisez un outil Application Performance and Monitoring. AppDynamics, ou un outil similaire, pourra vous aider à identifier les parties les moins performantes de votre code. Malheureusement, l'apprentissage de ces outils nécessite un peu d'apprentissage, mais ils peuvent s'avérer très utiles pour diagnostiquer les problèmes liés à vos applications.

Mettre à jour

Le redémarrage de votre pool d'applications peut aider à résoudre le problème en cas de fuite de mémoire, mais vous devez être prudent: il peut y avoir des effets néfastes. Après le redémarrage de votre pool d'applications, votre application commencera à charger des objets statiques dans la mémoire, etc. Selon la complexité de votre application, cela peut prendre un certain temps (5 à 10 minutes ou plus). Pendant ce temps, les demandes adressées à votre serveur peuvent être retardées, ce qui le rend apparaître que le problème est exacerbé.

Si vous exécutez un seul serveur, votre site peut devenir temporairement indisponible lors du redémarrage de l'application (en raison de l'occupation du pool d'applications et de l'impossibilité de répondre aux demandes). Si vous exécutez une batterie de serveurs avec un équilibreur de charge, celui-ci peut abandonner votre serveur pendant le redémarrage du pool d'applications, ce qui pourrait diriger tout le trafic vers d'autres serveurs et les surcharger. Ne redémarrez pas le pool d'applications sur tous vos serveurs en même temps et essayez de "réchauffer" les pools d'applications (en simulant des requêtes sur le serveur) avant de réintroduire des serveurs dans la batterie.

En d'autres termes: À moins que ce ne soit vraiment un problème de fuite de mémoire, il ne vaut peut-être pas la peine de redémarrer le pool d'applications, car le problème peut réapparaître immédiatement.

Remarque: Le redémarrage du pool d'applications entraînera ne pas impact sur les demandes en cours d'exécution. Celles-ci se poursuivront jusqu'à l'achèvement, à moins que vous ne fermiez de force le pool d'applications (par exemple, Crtl + Alt + Del)


13
2018-03-19 21:52



Belle réponse détaillée. - mfinni
C'est beaucoup de bonnes choses. Je vous remercie. - StephenCollins


Il se peut que le code soit de la merde et une fuite de mémoire, et qu'un redémarrage nocturne du pool d'applications réinitialise l'état de l'application. Avez-vous essayé de le déboguer de quelque manière que ce soit? Serveur de test, débogueur, profileur, le tout sous une charge qui ressemble à la production?

Je veux dire, cela vaut également la peine d'examiner les performances réelles du serveur pour s'assurer qu'il n'y a pas d'E / S lentes, ni autre chose qui se passe sur le serveur. Travaillez donc avec votre service informatique pour éliminer ce problème, bien sûr. Des mots tels que Perfmon, Solarwinds ou SCOM peuvent convenir, selon votre environnement. Cependant, vous devez également être disposé à travailler de votre côté.

J'ai été à la place du responsable informatique qui se fait reprocher des "applications Web lentes", alors qu'il n'y a littéralement aucun problème sur le serveur, mais qu'il y a des problèmes de code.


0
2018-03-19 20:30



Est-ce que je verrais quelque chose, comme une entrée de journal, qui indiquerait le pool d'applications qui redémarre et pourquoi? - StephenCollins
Cela dépend du niveau de journalisation. Vous ferez mieux de demander au service informatique lorsque le pool d'applications est configuré pour redémarrer; il peut être basé sur différents critères. Pour être clair: le redémarrage du pool d'applications ne pose pas de problème. Cela corrige un problème. - mfinni
Oui, je comprends ça. Je pense que je vous ai peut-être induit en erreur en utilisant les mots IT. Cela va vraiment être sur moi. Vous m'avez cependant donné des endroits pour commencer. - StephenCollins