Résoudre les erreurs PHP avec le suivi des demandes ayant échoué

S’applique à : Internet Information Services

Lors de l’exécution de PHP, il est parfois impossible d’inspecter une page d’erreur pour diagnostiquer une condition d’erreur. Cela peut se produire si :

• Vous ne savez pas quelle URL rencontre une erreur.
• L’erreur se produit par intermittence et vous ne pouvez pas la reproduire manuellement (l’erreur peut dépendre d’une entrée utilisateur ou de conditions de fonctionnement externes qui peuvent se produire rarement).
• L’erreur se produit uniquement dans l’environnement de production.

Dans ce cas, il est difficile de définir ce qu’est l’erreur, et encore plus difficile de la diagnostiquer. Vous pourrez peut-être déterminer quelles URL sont à l’origine des erreurs en inspectant les journaux des requêtes ou un journal des erreurs, mais il se peut que vous ayez toujours des difficultés à déterminer la cause de l’erreur.

Internet Information Services (IIS) facilite le suivi et le diagnostic de ces conditions d’erreur difficiles avec le suivi des demandes ayant échoué, ce qui vous permet de créer des définitions d’échec qui capturent automatiquement les traces d’exécution détaillées de certaines demandes. Consultez Résoudre les demandes ayant échoué à l’aide du suivi dans IIS et Utiliser le suivi des demandes ayant échoué pour suivre les règles de réécriture.

Pour faciliter l’diagnostics PHP, ces traces peuvent également être effectuées pour capturer les données d’entrée de requête et les données de réponse de PHP. Cela peut fournir les informations nécessaires pour diagnostiquer ces conditions d’erreur.

Un autre problème d’application assez courant est le code qui se bloque ou entre dans une boucle gourmande en ressources. Cela peut souvent se produire pour les raisons suivantes :

• Une opération d’E/S bloquante sur un fichier ou un réseau prend beaucoup de temps, par exemple lors de l’accès à un service web distant ou à une base de données.
• Le code a un bogue qui l’amène à entrer dans une boucle sans fin (ou de longue durée), éventuellement en faisant tourner le processeur ou en allouant de la mémoire.
• Le code se bloque ou interblocage sur une ressource ou un verrou partagé.

Ces conditions entraînent des temps d’attente ou des délais d’attente longs pour l’utilisateur qui effectue la demande, et les conditions peuvent également avoir un impact négatif sur les performances de l’application et même du serveur dans son ensemble.

IIS fournit un moyen rapide de déterminer quelles demandes sont suspendues en inspectant les demandes en cours d’exécution.

Utiliser le suivi des demandes ayant échoué pour diagnostiquer les erreurs inconnues ou difficiles à reproduire

Le suivi des demandes ayant échoué peut être un moyen efficace de suivre les conditions d’erreur intermittentes ou difficiles à reproduire et de diagnostiquer les conditions d’erreur en inspectant les détails de la demande, de la réponse et de la richesse des événements de trace des modules IIS.

Le suivi des demandes ayant échoué peut être utilisé dans un environnement de production, car il peut être configuré pour suivre uniquement les demandes qui répondent à la définition d’échec spécifique et peut éviter la majeure partie de la surcharge de suivi pour les demandes réussies.

Pour activer le suivi des demandes ayant échoué pour un site (dans cet exemple, nous utilisons TroubleshootingPhp), procédez comme suit :

1. Basculez vers le Gestionnaire des services Internet. S’il est fermé, sélectionnez Démarrer, puis Gestionnaire des services Internet (IIS).

2. Développez le nœud Serveur , puis développez le nœud Sites .

3. Dans l’arborescence à gauche, recherchez et sélectionnez le nom de votre site.

4. Sous IIS, double-cliquez sur Règles de suivi des demandes ayant échoué.
   

5. Dans le panneau Actions , sélectionnez Modifier le suivi de site.

6. Cochez la case Activer .

7. Sélectionnez OK.

8. À présent, créez une règle de suivi des demandes ayant échoué. Dans le panneau Actions , sélectionnez Ajouter.

9. Laissez l’option Tout le contenu sélectionnée.
   

10. Sélectionnez Suivant.

11. Entrez 400-999 dans Code(s) d’état.
    

12. Sélectionnez Suivant.

13. Laissez les fournisseurs de traces par défaut activés, puis sélectionnez Terminer.

14. À présent, vous pouvez effectuer des demandes. Supposons pour ces étapes que les demandes sont effectuées par d’autres utilisateurs de votre site et que vous n’êtes pas au courant de leurs demandes ou réponses. Par exemple, effectuez les requêtes suivantes à l’aide d’Internet Explorer :

    • Demande http://localhost:84/hello.php
    • Demande http://localhost:84/products.php?productid=3
    • Demande http://localhost:84/products.php?productid=5 (cette page génère une erreur)

15. Recherchez la trace de la demande ayant échoué :

    • Sélectionnez Démarrer, puis Invite de commandes pour ouvrir la fenêtre Invite de commandes.

    • Exécutez la commande suivante pour répertorier les journaux de trace générés pour notre site :

      %windir%\system32\inetsrv\appcmd.exe list traces /site.name:"TroubleshootingPhp"
      

    • Vous obtenez une sortie similaire à :

      TRACE "troubleshootingPhp/fr000001.xml" (url:http://localhost:84/products.php?product=5,statuscode:500,wp:2864)
      

    • La sortie indique qu’un journal de trace a été généré pour une requête adressée à /products.php?product=5, ce qui a entraîné une erreur HTTP 500. Il vous indique que :

      • La page Products.php a provoqué une erreur.
      • L’entrée à l’origine d’une erreur est probablement product=5, car vous ne voyez pas d’échecs pour d’autres chaînes de requête (cette conclusion serait plus précise si cette page est fréquemment consultée ; dans ce cas, vous voyez plusieurs erreurs uniquement pour cette chaîne de requête spécifique).

16. Vous pouvez maintenant obtenir un journal de trace spécifique pour collecter plus d’informations sur la demande et la cause possible de l’échec. Pour ce faire, exécutez la commande suivante à partir de l’invite de commandes (en utilisant l’ID entre guillemets du journal de suivi de la sortie précédente) :

    %windir%\system32\inetsrv\appcmd.exe list traces /site.name:"TroubleshootingPhp" /text:*
    

    La sortie doit ressembler à ce qui suit :

    TRACELOG
      TRACE.NAME:" troubleshootingPhp/fr000001.xml"
      PATH:"C:\inetpub\logs\FailedReqLogFiles\W3SVC2\fr000001.xml"
    URL:"http://localhost:84/products.php?product=5"
      STATUSCODE:"500"
      SITE.ID:"2"
      SITE.NAME:"TroubleshootingPhp"
      WP.NAME:"2864"
      APPPOOL.NAME:"TroubleshootingPhp"
      verb:"GET"
      remoteUserName:""
      userName:""
      tokenUserName:"NT
    AUTHORITY\IUSR"
      authenticationType:"anonymous"
      activityId:"{ 00000000-0000-0000-1400-0080000000FA }"
      failureReason:"STATUS_CODE"
      triggerStatusCode:"500"
      timeTaken:"100"
    xmlns:freb:"http://schemas.microsoft.com/win/2006/06/iis/freb"
    

17. Inspectez le journal de suivi. Ouvrez le fichier journal de trace dans le navigateur en utilisant le chemin d’accès spécifié dans la sortie précédente (dans cet exemple, il s’agitC:\inetpub\logs\FailedReqLogFiles\W3SVC2\fr000001.xml). L’onglet Résumé fournit des informations de base sur la demande. Vous pouvez voir que l’erreur status a été définie par fastCGIModule, ce qui suggère que l’erreur provient de PHP. Dans d’autres cas, vous pouvez voir que l’erreur provient d’autres modules IIS, auquel cas vous pouvez utiliser la richesse des informations de suivi dans le journal pour en déterminer la cause. Dans ce cas, toutefois, vous devez réellement voir la réponse qui a été générée par PHP pour obtenir plus d’informations sur l’erreur.
    

18. Sélectionnez l’onglet Vue compacte . Cet onglet affiche la liste détaillée des événements de trace générés par les modules IIS et IIS pendant le traitement de la requête.
    

    Remarque :

    • GENERAL_REQUEST_START’événement affiche des informations de base, notamment l’URL de la requête, le verbe, les informations d’exécution sur le site et l’application à laquelle la demande a été envoyée.
    • GENERAL_REQUEST_HEADERS’événement fournit la liste complète des en-têtes, ce qui, dans certains cas, peut être significatif pour déterminer quelle entrée utilisateur peut avoir conduit à l’erreur.
    • les événements GENERAL_RESPONSE_HEADERS et GENERAL_RESPONSE_ENTITY_BUFFER fournissent les en-têtes de réponse complets et le corps de la réponse qui a été envoyé au client. Dans ce cas, le corps de la réponse fournit les informations supplémentaires nécessaires pour diagnostiquer l’erreur, indiquant un ID de produit incorrect.

Voici d’autres sections que vous devez prendre en compte lors de l’inspection du journal de suivi :

• Le panneau Résumé de la demande fournit un résumé de la demande, son résultat et met également en évidence les événements d’avertissement ou d’erreur pendant l’exécution de la demande.
• Le panneau Détails de la demande fournit une vue hiérarchique de l’exécution de la demande, ce qui vous permet également de filtrer les événements par différentes catégories, telles que les notifications de module, l’authentification/autorisation, etc. Il offre également l’affichage des performances, qui vous aide à comprendre quelles parties de l’exécution ont pris le plus de temps.
• L’affichage compact offre la liste complète des événements, y compris une multitude d’informations sur l’exécution de la requête. La plupart des modules IIS produisent des informations sur leur exécution qui peuvent être utilisées pour comprendre différents aspects du traitement des demandes et du résultat. Ces informations peuvent être précieuses lors de la résolution des interactions complexes, telles que la réécriture d’URL ou l’authentification.

Localiser les demandes suspendues en inspectant l’exécution des requêtes en cours

Cela permet de déterminer rapidement quelles demandes sont suspendues en inspectant les demandes en cours d’exécution dans IIS.

Supposons que vous demandiez une page qui entre dans une boucle sans fin en raison d’un bogue de programmation. Dans les étapes suivantes, cette page est loop.php. Dans le gestionnaire de tâches, vous pouvez observer que le Php-cgi.exe est occupé, consommant près de 100 % du processeur (si vous avez plusieurs cœurs de processeur, vous voyez que le processus consomme 1/# de cœurs du total du processeur). Vous pouvez déterminer quelle demande est suspendue :

1. Sélectionnez Démarrer, puis Gestionnaire des services Internet (IIS).

2. Dans l’arborescence à gauche, sélectionnez le nœud Serveur .

3. Sous IIS, double-cliquez sur Processus de travail.

4. Sous Nom du pool d’applications, double-cliquez sur le nom de votre pool d’applications pour ouvrir la vue Demandes . (Dans cet exemple, il s’agit de TroubleshootingPhp.)
   

5. Basculez vers un navigateur web et actualisez la page si la page a expiré. Cette opération peut être nécessaire tout au long de ces étapes. Revenez au Gestionnaire des services Internet, puis actualisez la vue Demandes .

6. Observez la liste des requêtes en cours d’exécution, montrant la demande à la page du problème, dans cet exemple, /loop.php. L’entrée de demande indique :

   • Que la requête est en cours d’exécution depuis un certain temps (temps écoulé).
   • URL de la requête (dans cet exemple, /loop.php).
   • Nom du module (FastCGIModule).
   • Étape d’exécution (ExecuteRequestHandler).

Vous pouvez actualiser l’affichage plusieurs fois pour observer que la même requête continue à s’exécuter dans la même phase, en mettant en évidence la demande de suspension.

• Déterminez la requête qui se bloque à l’aide de l’invite de commandes. Avec l’invite de commandes, vous pouvez filtrer les demandes d’intérêt, par exemple les demandes adressées à une application spécifique ou à une URL spécifique. Il peut être utilisé pour automatiser les scripts qui surveillent les requêtes en cours d’exécution. Ouvrez la fenêtre Invite de commandes en sélectionnant Démarrer, puis Invite de commandes.

• Basculez vers un navigateur web, puis actualisez la http://localhost:84/loop.php page. (Notez que loop.php est un exemple de nom ; le nom de votre page doit être utilisé.) Vous devrez peut-être actualiser continuellement cette page pour les étapes suivantes. Basculez vers l’invite de commandes.

• Exécutez la commande suivante pour répertorier les demandes qui s’exécutent depuis plus d’une seconde :

  %windir%\system32\inetsrv\appcmd.exe list requests /elapsed:1000
  

  Vous obtenez une sortie similaire à ce qui suit, avec le nom de votre page au lieu de loop.php :

  REQUEST " fa000000080000026" (url:GET /loop.php, time:2840 msec, client:localhost, stage:ExecuteRequestHandler, module:FastCgiModule)
  

• Filtrez les requêtes retournées en spécifiant un nombre quelconque de critères en fonction des attributs de requête disponibles. Par exemple, pour afficher uniquement les requêtes à une URL spécifique :

  %windir%\system32\inetsrv\appcmd.exe list requests /url:/loop.php /elapsed:1000
  

• Vous pouvez également utiliser la liaison de commande AppCmd pour effectuer des requêtes plus complexes, par exemple, pour déterminer toutes les applications qui ont des requêtes de longue durée :

  %windir%\system32\inetsrv\appcmd.exe list requests /elapsed:1000 /xml | %windir%\system32\inetsrv\appcmd list apps /in
  

  Vous obtenez la liste des applications similaires à ce qui suit :

  APP "troubleshootingPhp/" (applicationPool:troubleshootingPhp)
  

• Voici un exemple d’action basée sur les données de requête actuelles : le recyclage des pools d’applications avec des requêtes exécutées depuis plus de cinq secondes :

  %windir%\system32\inetsrv\appcmd.exe list requests /elapsed:1000 /xml | %windir%\system32\inetsrv\appcmd list apppools /in /xml | %windir%\system32\inetsrv\appcmd recycle apppools /in
  

  Vous obtenez la sortie suivante, avec le nom de votre application :

  "TroubleshootingPhp" successfully recycled
  

Plus d’informations

• Gestion et journalisation des erreurs