Condividi tramite


Risolvere gli errori PHP con Tracciamento delle Richieste Fallite

Si applica a: Internet Information Services

Quando si esegue PHP, a volte non è possibile esaminare una pagina di errore per diagnosticare una condizione di errore. Ciò può verificarsi se:

  • Non sai quale URL stia riscontrando un errore.
  • L'errore si verifica in modo intermittente e non è possibile riprodurlo manualmente (l'errore può dipendere dall'input dell'utente o da condizioni operative esterne che possono verificarsi raramente).
  • L'errore si verifica solo nell'ambiente di produzione.

In questi casi, è difficile definire l'errore e persino più difficile diagnosticarlo. È possibile determinare gli URL che causano gli errori esaminando i log delle richieste o un log degli errori, ma è comunque possibile che si verifichino problemi durante la determinazione di ciò che ha causato l'errore.

Internet Information Services (IIS) semplifica il rilevamento e la diagnosi di queste difficili condizioni di errore con Traccia richieste non riuscite, che consente di creare definizioni di errore che acquisiscono automaticamente tracce di esecuzione dettagliate di determinate richieste. Vedere Risolvere i problemi relativi alle richieste non riuscite usando la traccia in IIS e Usare traccia delle richieste non riuscite per tracciare le regole di riscrittura.

Per semplificare la diagnostica PHP, è anche possibile creare queste tracce per acquisire i dati di input della richiesta e i dati di risposta da PHP. Ciò può fornire le informazioni dettagliate necessarie per diagnosticare queste condizioni di errore.

Un altro problema di applicazione abbastanza comune è il codice che si blocca o entra in un ciclo a elevato utilizzo di risorse. Ciò può verificarsi spesso perché:

  • Il completamento di un'operazione di I/O bloccante su un file o una rete richiede molto tempo, ad esempio quando si accede a un servizio Web remoto o a un database.
  • Il codice ha un bug che lo fa entrare in un ciclo infinito (o a esecuzione prolungata), possibilmente anche ruotando la CPU o allocando la memoria.
  • Il codice si blocca o va in deadlock su una risorsa o un blocco condiviso.

Queste condizioni comportano tempi di attesa lunghi o timeout per l'utente che effettua la richiesta e le condizioni possono anche influire negativamente sulle prestazioni dell'applicazione e persino sul server nel suo complesso.

IIS offre un modo rapido per determinare quali richieste sono bloccate controllando le richieste attualmente in esecuzione.

Usare la traccia delle richieste non riuscite per diagnosticare errori sconosciuti o difficili da riprodurre

La traccia delle richieste non riuscite può essere un modo efficace per tenere traccia delle condizioni di errore intermittenti o difficili da riprodurre e diagnosticare le condizioni di errore esaminando i dettagli relativi alla richiesta, alla risposta e alla ricchezza di eventi di traccia dai moduli IIS.

La traccia delle richieste non riuscite può essere usata in un ambiente di produzione perché può essere configurata per tracciare solo le richieste che soddisfano la definizione di errore specifica e può evitare la maggior parte del sovraccarico di traccia per le richieste riuscite.

Per abilitare la traccia delle richieste non riuscite per un sito (in questo esempio si usa TroubleshootingPhp), seguire questa procedura:

  1. Passare a Manager IIS. Se è chiuso, selezionare Start e quindi Gestione Internet Information Services (IIS).

  2. Espandere il nodo Server e quindi espandere il nodo Siti .

  3. Nella visualizzazione albero a sinistra individuare e selezionare il nome del sito.

  4. In IIS fare doppio clic su Regole di traccia richieste non riuscite.
    Screenshot della sezione I S con lo stato attivo sull'icona Regole di traccia delle richieste non riuscite.

  5. Nel pannello Azioni selezionare Modifica il tracciamento del sito.

  6. Selezionare la casella Abilita.

  7. Seleziona OK.

  8. Ora, crea una regola di traccia delle richieste non riuscite. Nel pannello Azioni selezionare Aggiungi.

  9. Lasciare selezionata l'opzione Tutto il contenuto .
    Screenshot della finestra di dialogo Aggiungi regola di traccia delle richieste non riuscite con l'opzione Tutto il contenuto selezionata.

  10. Seleziona Avanti.

  11. Immettere 400-999 nei codici di stato.
    Screenshot della schermata Definisci condizioni di traccia con 4 0 0 trattino 9 9 9 immesso come codice di stato.

  12. Seleziona Avanti.

  13. Lasciare abilitati i provider di traccia predefiniti e quindi selezionare Fine.

  14. È ora possibile effettuare richieste. Si supponga che per questi passaggi le richieste vengano effettuate da altri utenti del sito e che non si siano a conoscenza delle richieste o delle risposte. Ad esempio, effettuare le richieste seguenti usando Internet Explorer:

    • Richiedere http://localhost:84/hello.php
    • Richiedere http://localhost:84/products.php?productid=3
    • Richiesta http://localhost:84/products.php?productid=5 (questa pagina genera un errore)
  15. Trovare la traccia della richiesta non riuscita:

    • Selezionare Start e quindi selezionare Prompt dei comandi per aprire la finestra del prompt dei comandi.

    • Eseguire il comando seguente per elencare i log di traccia generati per il sito:

      %windir%\system32\inetsrv\appcmd.exe list traces /site.name:"TroubleshootingPhp"
      
    • Si ottiene un output simile al seguente:

      TRACE "troubleshootingPhp/fr000001.xml" (url:http://localhost:84/products.php?product=5,statuscode:500,wp:2864)
      
    • L'output indica che è stato generato un log di traccia per una richiesta a /products.php?product=5, che ha generato un errore HTTP 500. Indica che:

      • La pagina Products.php ha causato un errore.
      • L'input che ha causato un errore è molto probabile product=5, perché non vengono visualizzati errori per altre stringhe di query( questa conclusione sarebbe più precisa se si accede di frequente a questa pagina; in tal caso vengono visualizzati più errori solo per questa stringa di query specifica).
  16. È ora possibile ottenere un log di traccia specifico per raccogliere altre informazioni sulla richiesta e sulla possibile causa dell'errore. A tale scopo, eseguire il comando seguente dal prompt dei comandi (usando l'ID tra virgolette del log di traccia dell'output precedente):

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

    L'output dovrebbe essere simile al seguente:

    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. Esaminare il log di traccia. Aprire il file di log di traccia nel browser usando il percorso specificato nell'output precedente (in questo esempio c :\inetpub\logs\FailedReqLogFiles\W3SVC2\fr000001.xml). La scheda Riepilogo fornisce informazioni di base sulla richiesta. È possibile notare che lo stato dell'errore è stato impostato da FastCGIModule, che suggerisce che l'errore proviene da PHP. In altri casi, è possibile notare che l'errore proviene da altri moduli IIS, nel qual caso è possibile usare la ricchezza di informazioni di traccia nel log per determinare la causa. In questo caso, tuttavia, è necessario visualizzare effettivamente la risposta generata da PHP per ottenere maggiori informazioni sull'errore.
    Screenshot nella scheda Riepilogo della richiesta della pagina di diagnostica delle richieste.

  18. Selezionare la scheda Visualizzazione compatta. Questa scheda mostra l'elenco dettagliato degli eventi di traccia generati dai moduli IIS e IIS durante l'elaborazione della richiesta.
    Schermata della diagnostica delle richieste con la scheda Visualizzazione compatta evidenziata.

    Nota:

    • GENERAL_REQUEST_START evento mostra alcune informazioni di base, tra cui l'URL della richiesta, il verbo, le informazioni di runtime sul sito e l'applicazione a cui è stata inviata la richiesta.
    • L'evento GENERAL_REQUEST_HEADERS fornisce l'elenco completo delle intestazioni, che in alcuni casi può essere significativo per determinare quale input dell'utente abbia portato all'errore.
    • GENERAL_RESPONSE_HEADERS e gli eventi GENERAL_RESPONSE_ENTITY_BUFFER forniscono le intestazioni di risposta complete e il corpo della risposta inviato al client. In questo caso, il corpo della risposta fornisce le informazioni aggiuntive necessarie per diagnosticare l'errore, indicando un ID prodotto non corretto.

Queste sono altre sezioni da considerare durante l'analisi del log di traccia:

  • Il pannello Riepilogo richieste fornisce un riepilogo della richiesta, il relativo risultato ed evidenzia anche eventuali eventi di avviso o di errore durante l'esecuzione della richiesta.
  • Il pannello Dettagli richiesta offre una visualizzazione gerarchica dell'esecuzione della richiesta, consentendo anche di filtrare gli eventi in base a varie categorie, ad esempio Notifiche modulo, Autenticazione/Autorizzazione e così via. Offre anche la visualizzazione prestazioni, che consente di comprendere quali parti dell'esecuzione hanno richiesto più tempo.
  • Compact View offre l'elenco completo degli eventi, tra cui una vasta gamma di informazioni sull'esecuzione della richiesta. Molti moduli IIS producono informazioni sull'esecuzione che possono essere usate per comprendere vari aspetti dell'elaborazione della richiesta e del risultato. Queste informazioni possono essere utili per la risoluzione dei problemi relativi a interazioni complesse, ad esempio la riscrittura o l'autenticazione degli URL.

Individuare le richieste in sospeso controllando l'esecuzione delle richieste correnti

In questo modo è possibile determinare rapidamente quali richieste sono bloccate esaminando le richieste attualmente in esecuzione in IIS.

Si supponga di richiedere una pagina che entra in un ciclo infinito a causa di un bug di programmazione. Nei passaggi seguenti questa pagina è loop.php. In Gestione attività è possibile osservare che la Php-cgi.exe è occupata, consumando quasi il 100% della CPU (se si dispone di più core CPU, viene visualizzato il processo che usa 1/# di core della CPU totale). È possibile determinare quale richiesta è in sospeso:

  1. Selezionare Start, e quindi selezionare Gestione Internet Information Services (IIS).

  2. Nella visualizzazione albero a sinistra selezionare sul nodo Server .

  3. In IIS fare doppio clic su Processi di lavoro.

  4. Sotto Nome del pool di applicazioni, fare doppio clic sul nome del pool di applicazioni per aprire la visualizzazione Richieste. (In questo esempio è TroubleshootingPhp.)
    Screenshot della schermata Processi di lavoro con il nome del pool di applicazioni evidenziato.

  5. Passare a un Web browser e aggiornare la pagina se la pagina è scaduta. Potrebbe essere necessario eseguire questa operazione in questi passaggi. Tornare a Gestione IIS e quindi aggiornare la visualizzazione Richieste .

  6. Osservare l'elenco delle richieste attualmente in esecuzione, che mostra la richiesta alla pagina del problema, in questo esempio / loop.php. La voce della richiesta mostra:

    • Che la richiesta sia stata eseguita per un certo periodo di tempo (tempo trascorso).
    • URL della richiesta (in questo esempio / loop.php).
    • Nome del modulo (FastCGIModule).
    • Fase di esecuzione (ExecuteRequestHandler).

È possibile aggiornare la visualizzazione più volte per osservare che la stessa richiesta continua a essere eseguita nella stessa fase, indicando la richiesta sospesa.

  • Individuare quale richiesta è bloccata usando il prompt dei comandi. Con il prompt dei comandi è possibile filtrare le richieste di interesse, ad esempio le richieste a un'applicazione specifica o a un URL specifico. Può essere usato per automatizzare gli script che monitorano le richieste attualmente in esecuzione. Aprire la finestra del prompt dei comandi selezionando Avvia e quindi selezionando Prompt dei comandi.

  • Passare a un Web browser e quindi aggiornare la http://localhost:84/loop.php pagina. Si noti che loop.php è un nome di esempio. Il nome della pagina deve essere usato. Potrebbe essere necessario aggiornare continuamente questa pagina per i passaggi seguenti. Passare al prompt dei comandi.

  • Eseguire il comando seguente per elencare le richieste in esecuzione per più di un secondo:

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

    Si ottiene un output simile al seguente, con il nome della pagina anziché loop.php:

    REQUEST " fa000000080000026" (url:GET /loop.php, time:2840 msec, client:localhost, stage:ExecuteRequestHandler, module:FastCgiModule)
    
  • Filtrare le richieste restituite specificando un numero qualsiasi di criteri in base agli attributi della richiesta disponibili. Ad esempio, per visualizzare solo le richieste a un URL specifico:

    %windir%\system32\inetsrv\appcmd.exe list requests /url:/loop.php /elapsed:1000
    
  • È anche possibile usare il collegamento dei comandi AppCmd per eseguire query più complesse, ad esempio per determinare tutte le applicazioni con richieste con esecuzione prolungata:

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

    Viene visualizzato l'elenco di applicazioni simili alle seguenti:

    APP "troubleshootingPhp/" (applicationPool:troubleshootingPhp)
    
  • Ecco un esempio di esecuzione di un'azione basata sui dati della richiesta correnti: riciclare i pool di applicazioni con richieste in esecuzione per più di cinque secondi:

    %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
    

    Si ottiene l'output seguente, con il nome dell'applicazione:

    "TroubleshootingPhp" successfully recycled
    

Ulteriori informazioni