1 votes

Premier contact lent avec le service Web ASMX après la mise à niveau vers Windows Server 2008 et IIS 7.5

Nous avons récemment fait construire un nouveau serveur de production pour servir une application commerciale ASP.NET 4.0. Les spécifications du nouveau serveur sont les suivantes : Windows Server 2008 R2, Xenon à 2 cœurs, IIS 7.5, 2 Go de RAM (bientôt 4 Go). Avant le nouveau serveur, nous avions exécuté/testé l'application sur un Windows Server 2003, à un seul cœur, IIS 6, 4 Go de RAM.

Notre application utilise un service web ASMX pour valider les logins par rapport à Active Directory en utilisant LDAP.

Nous avons immédiatement constaté une augmentation significative des temps de réponse lors de l'utilisation du service web à partir du nouveau serveur, mais uniquement lors du "premier essai". Curieusement, 99,9% du temps, le temps de réponse pour ce "premier accès" est de 15 secondes (littéralement entre 15000 et 15999ms). Les visites suivantes donnent lieu à des temps de réponse typiques (<100ms - 300ms) pour tous les utilisateurs. Toutefois, si vous attendez plus de 2 à 3 minutes, le comportement du "premier coup" se reproduira.

Les temps de réponse au même service, sur l'ancien serveur, ne dépassent jamais 300 ms... Même après avoir redémarré IIS6.

La route de traçage pour les anciens et les nouveaux serveurs est exactement la même. Idem pour les temps de réponse Ping.

Après de nombreux essais, la seule façon fiable de reproduire (et donc de définir le "premier coup") est la suivante :

a) attendre 2-3 minutes, ou

b) recycler le pool d'applications, ou

c) redémarrer IIS

L'application fonctionne sous son propre pool d'applications, en utilisant le Framework .NET 4.0.

Voici l'état actuel de l'application et de IIS :

  • Recyclage désactivé pour tous les pools (Idle Timeout & Fixed Intervals)
  • Aucune référence de débogage dans le Web.config
  • L'application est précompilée (publiée via Visual Studio)
  • Pipeline géré = intégré
  • Identité = NetworkService
  • Exécution en mode 64 bits (le passage en mode 32 bits n'a eu aucun effet)

J'ai d'abord pensé qu'il s'agissait d'un problème de recyclage, car j'ai vu de nombreux messages à ce sujet. Cependant, cela n'explique pas pourquoi le comportement de " première frappe " se produit après seulement 2 ou 3 minutes d'attente.

La seule chose que je n'ai pas essayée est le Warm-Up de IIS. Ceci parce que a) je n'ai pas les droits pour l'installer et b) dans mon esprit, le "first-hit" est la page de connexion, pas le service (sauf erreur de ma part). La page de connexion se charge en moins de 300 ms, qu'il s'agisse d'un "first-hit" ou non.


Une autre note... Nous avons en fait deux nouveaux serveurs de production, qui sont identiques. Une de nos autres applications utilise l'équilibrage de charge sur les deux serveurs. L'application en question n'est située que sur l'un des serveurs et n'est pas équilibrée en charge. Cela pourrait-il avoir un rapport avec le problème ?

J'espère que vous pourrez m'aider !

0voto

jellenberger Points 141

Nos informaticiens ont donc fini par régler le problème.

Bien qu'ils ne soient pas exactement sûrs de la nature du problème, ils pensent que c'est parce que deux adresses IP sont associées à notre nom de domaine (pour l'équilibrage de charge). Depuis la configuration et le démarrage de Round Robin (VMWare), le problème semble s'être résolu de lui-même.

0 votes

Je sais que j'arrive un peu tard dans la soirée, mais merci d'avoir mis à jour votre question.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X