Troubleshooting PHP Issues: Gute (und schlechte) Techniken

Troubleshooting PHP Issues

Jan Burkl
System Engineer
jan@zend.com

Das Webinar kann hier angeschaut werden:
http://www.zend.com/de/webinar/PHP/70170000000bTBC-
Troubelshooting-PHP-issues-20110301-DE.flv
© All rights reserved. Zend Technologies, Inc.

Code Qualität und der Einfluss auf
Entwicklungszeit und -kosten
Quelle: Boehm und Papaccio Studie

• Fehlerhafter Code verbraucht typischerweise zwischen 40% und 50% der
gesamten Projektkosten
• Jede für Fehlersuche und Fehlerbehebung aufgebrachte Stunde in der
Entwicklung reduziert die Maintenance Zeit um 3 bis 10 Stunden
• Leider werden nicht alle Bugs während der Entwicklungs- oder Q/A-Phase
entdeckt…

Was werden wir heute besprechen?

Typen von PHP Problemen
Error Logging
Probleme reproduzieren
Code Tracing
Demo


Allgemeine PHP Issues
 E_ERROR (Fatal Errors)
 E_WARNING (Problematisch, aber keine Fatal Errors)
 E_NOTICE (nicht kritisch, können auf ein Fehler hinweisen)
 E_PARSE (nicht zur Laufzeit, durch den Parser generiert)
 E_STRICT (Vorschläge)
 E_RECOVERABLE_ERROR (Catchable Fatal Error, seit PHP 5.2)
 E_DEPRECATED (seit PHP 5.3)
 E_USER_* (User generierte Events, durch trigger_error())


Andere Problemtypen

• Logische Fehler
 Z.B. inkorrekte Berechnungen, fehlerhafte SQL Querys, etc.

• Schlechte Performance
 Z.B. teure Datenbankzugriffe, Speicherverbrauch, etc.

• Security Issues
 Z.B. Code Angreifbarkeit, PHP Settings

• Diese Probleme äußern sich nicht in PHP Fehlern


PHP Errors – Best Practices

 Während Entwicklungs- und Testphase sollten alle
Fehler angezeigt werden:
 error_reporting = E_ALL
 display_errors = on

 Im Produktionsumfeld nur die wichtigsten Fehler
aktivieren:
 error_reporting = E_ALL & ~E_NOTICE
 display_errors = off

• Zur Laufzeit können error_reporting() und
ini_set(“display_errors”, value) benutzt werden


Beispiel
Dieses Beispiel erzeugt eine Notice, zwei Warnungen
und einen Fatal Error:

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
$num = 5 / $div;
require 'utility.inc';

• Notice: Undefined variable: div in test.php on line 4
• Warning: Division by zero in test.php on line 4
• Warning: require(utility.inc) [function.require]: failed to open stream:
No such file or directory in test.php on line 5
• Fatal error: require() [function.require]: Failed opening required
'utility.inc' (include_path='.:...') in test.php on line 5

Custom Errors Events

• Ein aus PHP heraus generiertes Event wird an den Default
Output gesendet
• Die Events können in ein Log File geschrieben werden 
error_log Direktive in php.ini
• Der Error Handler kann mit Hilfe der Funktion
set_error_handler() angepasst werden
• Z.B. eine E-Mail an den Admin bei einem Error schicken
• Fatal Errors können nicht mit set_error_handler()
behandelt werden
• Zur Erinnerung: Fatal Errors (E_ERROR) stoppen die
Ausführung eines PHP Skripts!


Zend Studio: Probleme während der
Entwicklung und des Testens lokalisieren

• Parse Errors (E_PARSE)
entdecken ohne den Code
auszuführen
• Aufspüren von logischen
Fehlern, die Fatal Errors
bedingen könnten
• Lokales oder Remote Debugging
(mit Zend Server)
• Code Profile
 Performance Probleme finden

 Code Coverage benutzen


No need to die()…

• Zend_Log, Firebug, FirePHP
protected function _initLog() {
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);

Zend_Registry::set('logger', $logger);
}

// Controller action
$logger = Zend_Registry::get('logger');
$logger->info('event: ' . $eventId);
$logger->info($event);
$logger->warn("event starts after 3pm");
$logger->err($exception);


PHP Error Logs für Troubleshooting

• Error Logs sind hilfreich während der Entwicklung, des
Testens und in der Produktion
• Trotzdem gibt es einige Begrenzungen
Keine Hilfe bei Performance Problemen
Keine Hilfe bei logischen Fehlern
Notwendigkeit der Problemreproduktion – schwierig in der
Produktion!
Bietet nur eine beschränkte Sicht auf die Probleme – es
fehlt der Kontext


Application Level Monitoring
in Zend Server
• Zend Server Monitor überwacht die Applikation nach:
 PHP Fehlern (einschließlich Warnings, Notices, Uncaught
Exceptions, …)
 Fehlgeschlagene Funktionsaufrufe (user-defined oder intern)

 Fehlgeschlagene DB Querys

 Langsame Funktionsaufrufe (user-defined oder intern)

 Slow Request Execution

 Hoher Speicherverbrauch

 Von Zend Server Komponenten

entdeckte Fehler


Zend Server - Events


Ursachenanalyse
• Wiederkehrende Events werden aggregiert und auf
einer Zeitleiste angeordnet
 Wann wiederholt sich ein Problem?

• Jeder Event Report beinhaltet Kontext Informationen,
die beim Debuggen unterstützen
 URL, File, Line, Error Message, Repeat Count, etc.

 Request Information (GET, POST, COOKIE, etc.)

 Server Information

 Session Information

 Backtrace (wenn relevant)


Integration in Zend Studio
• Zend Server integriert Zend Studio und bietet die
Möglichkeit, ein Event nochmals durchzuführen
 In einer Debug Session

 In einer Profile Session

 Durch einen Klick in der GUI

 … oder, durch Exportieren der Event Daten, danach
Import in die IDE
 “Replay” auf alternativem Test Server

• In vielen Fällen eliminiert es die Zeit zur Reproduktion

Zend Framework Monitoring mit Zend Server

• Alle Monitoring Funktionen von Zend Server arbeiten
natürlich auch für Zend Framework Applikationen
• Zend_Log_Writer_ZendMonitor()


Zend Framework Monitoring mit Zend Server

• All automatic monitoring capabilities of Zend Server also
work for Zend Framework projects just like any other PHP
application
• Zend_Log_Writer_ZendMonitor() can save


Release von PHP Code in die Produktion
• PHP Code sollte fehlerfrei (zumindest ohne E_WARNING
und E_ERROR), wenn es releast wird
• Warum treten trotzdem Fehler in der Produktion auf?
• Unterschiede in der Produktionsumgebung
• Andere Last in der Produktion
• Echte User nutzen die Applikation anders als Entwickler und
Tester antizipiert haben
• Infrastrukturkomponenten oder Back-End Systeme schlagen
fehl oder ändern sich
• Murphy's law - "Anything that can go wrong will go wrong.“ 


Code Tracing – Data Capture
• Reproduktion ist nicht immer möglich
 Abhängigkeit von spezifischem SESSION-Status.

 Abhängigkeit von spezifischem Datenbank-Status.

 “Wiederholung“ des Requests ist riskant oder unmöglich.

• Code Tracing ist in der Lage den gesamten Execution Flow zu
erfassen.
 Execution Tree inklusive Funktionsaufrufen und inkludierten Files.

 Funktions-Argumente und Return-Parameter.

 Output und HTTP-Header-Generierung.

 Lokation von Fehlern, Exceptions und Zend Monitor Events.

 Für jeden Knoten wird Ausführungszeit und Speicherverbrauch gemessen.


Code Tracing


Code Tracing
• Code Trace-Daten werden generiert durch
 manuelle Requests

 Monitoring-Events

 Durch API

• Code Tracing erfasst folgende Informationen:
 Execution Tree inklusive Funktionsaufrufen und inkludierten Files.

 Funktions-Argumente und Return-Parameter.

 Output und HTTP-Header-Generierung.

 Lokation von Fehlern, Exceptions und Zend Monitor Events.

 Für jeden Knoten wird Ausführungszeit und Speicherverbrauch gemessen.


Zend Server Code Tracing:
Verringert die Zeit der Ursachenanalyse
• Speichert den Live-Anwendungsablauf bei Problemauftritt
• Aktivierung durch Zend-Server Monitoringregeln oder
manuell
• Funktioniert im Produktions- oder im Testumfeld -
eliminiert die Notwendigkeit Probleme zu reproduzieren

Problemlösungszeit Ursachen-Analyse
Lösung
ohne Code Tracing Problemreproduktion – Debug

Ursachen-Analyse
Problemlösungszeit Lösung
Code Trace-Analyse
mit Code Tracing


Demo!


Dankeschön!
jan@zend.com


Webinar

Das Webinar kann hier angeschaut werden:
http://www.zend.com/de/webinar/PHP/70170000000bTBC-
Troubelshooting-PHP-issues-20110301-DE.flv
oder
http://bit.ly/oMw3QZ

(nach einer kurzen Registrierung)

26 © All rights reserved. Zend Technologies, Inc.

Troubleshooting PHP Issues: Gute (und schlechte) Techniken

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Zend by Rogue Wave Software

Mais de Zend by Rogue Wave Software (20)

Troubleshooting PHP Issues: Gute (und schlechte) Techniken