09 septembre 2013
publié par 
Le principe nécessaire à la conservation d'un "contexte" pour l'Internaute qui navigue dans un site dynamique WEBDEV a été détaillé dans le billet suivant du blog :

Suite à une remontée au support sur une apparente consommation excessive de CPU/processeur sur un serveur Web au niveau du module WDAWP.EXE (WD170AWP.EXE en version 17, WD180AWP.EXE en version 18), j'ajoute ce billet qui permettra d'avoir le cheminement complet du traitement nécessaire aux requêtes des utilisateurs d'un site dynamique. Car comme toujours, lorsque l'on connaît le principe complet, il est bien plus facile de rechercher l'origine d'un comportement imprévu !

Dans le billet relatif aux sessions nécessaires à la gestion de chaque connexion, le module WDSESSION.EXE (WD170SESSION.EXE en version 17, WD180SESSION.EXE en version 18), a été détaillé. C'est ce module qui fait la majeure partie du travail sur le serveur, notamment toutes les exécutions des codes serveurs du site. Le rôle de WD180AWP.EXE bien que totalement indispensable est donc minime : il s'agit uniquement d'un programme "lanceur" qui va transformer une demande HTTP reçue par le serveur Web (IIS, Apache...). En résumé :
  • l'internaute demande l'accès à un site dynamique : http://MonSite ou http://serveur/WD180AWP.EXE/WD180AWP.EXE/CONNECT/MonSite
  • le serveur Web grâce au répertoire virtuel, ou alias, WD180AWP qui lui a été ajouté fait le lancement du module WD180AWP.EXE,
  • le module WD180AWP.EXE fait le lancement d'une nouvelle instance de WD180SESSION.EXE si il s'agit d'une nouvelle connexion, ou passe les paramètres reçus du serveur Web à une instance WD180SESSION.EXE existante, dans le cas d'une demande pour une connexion existante,
  • le module WD180AWP.EXE attend la réponse de WD180SESSION.EXE, puis se termine immédiatement.

Si à un instant donné par le gestionnaire de processus on observe une persistance en mémoire d'un WD180AWP.EXE, avec une importante activité du processeur :
  • ce n'est pas directement que le module est en train d'exécuter un traitement. En effet, c'est uniquement un lanceur, il ne peut qu'être en attente du lancement d'une instance de WD180SESSION.EXE. Windows montre dans ce cas une utilisation complète du processeur, ou du coeur, si ce dernier n'est pas sollicité par d'autres processus. Mais il s'agit d'une attente non prioritaire, le processeur reste libre si d'autres processus l'utilisent.
  • c'est donc un module WD180SESSION.EXE qui ne peut pas être lancé, ou qui ne répond plus si un traitement trop long lui a été demandé.

A noter qu'un échec complet du lancement de WD180SESSION.EXE par WD180AWP.EXE peut se solder par le retour ERR_LAUNCH_FAILED au niveau du navigateur.

Le billet précédente relatif à WD180SESSION.EXE donne déjà des cas qui peuvent conduire à un blocage. Le plus fréquemment il s'agit :
  • d'un code serveur trop coûteux en temps et/ou en ressource qui devrait être déporté en back-office,
  • d'un code en erreur pour lequel un timeout est trop long (par exemple la perte d'une connexion avec un serveur de données auquel le code serveur tente de se connecter),
  • trop de sessions sont lancées (ressources nécessaires pour une session * nombre de connexions > ressources disponibles sur le serveur) ...

Dans tous les cas une surveillance des WD180SESSION.EXE via le gestionnaire de processus sur le serveur permet de comprendre ce qu'il se passe, en recoupant si besoin avec les remontées de l'observateur d'événement de Windows, et/ou les logs des sessions.

< Retour

Publier un commentaire : 
Votre adresse email ne sera pas publiée