Profilierung von PHP-Code. XHProf und xDebug – Profilierung von PHP-Code unter Verwendung zusätzlicher Interpreterparameter

xhprof für PHP installieren:

Sudo apt-get install php5-xhprof

Apache neu starten:

Neustart des Sudo-Dienstes Apache2

Drucken Sie phpinfo(); und prüfen, ob das Modul angeschlossen ist oder nicht?

Wir überprüfen /etc/php5/apache2/conf.d, um zu sehen, ob dort ein Link zur xhprof.ini-Konfiguration erscheint.

Wenn nicht, erstellen Sie den Link selbst und starten Sie Apache neu.

Sudo ln -s /etc/php5/mods-available/xhprof.ini /etc/php5/apache2/conf.d/20-xhprof.ini sudo service apache2 neu starten

Wir überprüfen die xhprof-Verbindung und prüfen, ob 20-xhprof.ini verbunden ist:

Der Screenshot zeigt Version 0.9.2, bei der Installation wurde zwar Version 0.9.4 angezeigt, was für uns aber kein Hindernis darstellt.

Jetzt können wir unseren Code profilieren.

1. Aktivieren Sie am Anfang der Seite die Profilerstellung mit xhprof_enable();
2. Am Ende der Seite deaktivieren Sie die Profilerstellung mit xhprof_disable() und speichern die gesammelten Daten mit save_run();
3. Als nächstes analysieren wir.

Funktion xhprof_enable() akzeptiert Flags als Argumente:

XHPROF_FLAGS_CPU zur Aufzeichnung von Prozessorstatistiken,

XHPROF_FLAGS_MEMORY – für Speicher,

XHPROF_FLAGS_NO_BUILTINS – um integrierte Funktionen zu ignorieren.

Zur Speicherung und weiteren Nachbesprechung müssen wir ein Profilanalysetool installieren.

Laden Sie das Archiv mit dem Analysetool von der Seite xhprof: herunter, nehmen Sie Version 0.9.4.

Erstellen Sie auf dem Server oder lokalen PC einen über localhost oder eine separate Domäne zugänglichen Ordner, in den wir das heruntergeladene Archiv entpacken:

Jetzt können wir das Profil speichern.

https://xn--d1acnqm.xn--j1amh/altadmin/posts/edit/188

Der Tracking-Code sieht in etwa so aus:

// Profiler initialisieren – wir zählen sowohl Prozessorzeit als auch Speicherverbrauch xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
// Profilierter Code # Stoppen Sie den Profiler $xhprof_data = xhprof_disable(); # Speichern Sie den Bericht und generieren Sie einen Link, um ihn anzuzeigen include_once "/var/www/html/xhprof-0.9.4/xhprof_lib/utils/xhprof_lib.php"; include_once "/var/www/html/xhprof-0.9.4/xhprof_lib/utils/xhprof_runs.php"; $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test"); echo "Bericht: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=$run_id&source=xhprof_test"; echo "\n";

/var/www/html/xhprof-0.9.4 – der Pfad zu dem Ordner, in den wir die benötigten Bibliotheken entpackt haben.

Bericht: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=57c32f3095d21&source=xhprof_test

So sieht eine Profilanalyse aus. In dieser Tabelle werden alle Funktionsaufrufe angezeigt, für die ein Profil erstellt wurde.

Wir können die Funktionen sortieren, indem wir auf die Tabellenüberschriften klicken.

Wenn wir sehen, dass eine Funktion mehrmals oder sehr lange ausgeführt wird, können wir auf diese Funktion klicken und eine ähnliche Tabelle wird geöffnet, jedoch mit internen Aufrufen innerhalb der betreffenden Funktion und der übergeordneten Umgebung, in der die Funktion aufgerufen wurde.

Indikatoren:
Total Inc. Wall Time (Zeit, die für die Ausführung von Funktionen aufgewendet wird, unter Berücksichtigung des Wartens auf Antworten von Sockets, dem Dateisystem und anderen Ressourcen)
Total Inc. CPU (Zeitaufwand für die Ausführung von Funktionen)
Total Inc. MemUse (Speichernutzung)
Total Inc. PeakMemUse (Spitzenspeichernutzung)
Anzahl der Funktionsaufrufe

Es besteht auch die Möglichkeit, den Bericht grafisch darzustellen. Dazu müssen Sie jedoch sicherstellen, dass die graphviz-Bibliothek installiert ist:

Apt-get install graphviz

Dann müssen Sie in Ihrem Profil auf „Anzeigen“ klicken und voilà:

Jetzt können Sie den Code analysieren und verbessern.

FirePHP ist eine Erweiterung für Firebug, die es Ihnen in Verbindung mit ihrer kleinen PHP-Klasse ermöglicht, Daten von PHP, zum Beispiel alle Arten von var_dump und anderen Debugging-Informationen, an die Firebug-Konsole zu übertragen Alle Debugging-Informationen werden über Header übertragen und verunreinigen nicht die Seiten und beeinträchtigen in keiner Weise die Logik der Anwendung: http://firephp.org/.

Hauptidee.

Der allgemeine Profilierungsalgorithmus lautet wie folgt:

1. Am Anfang der Seite aktivieren wir die Profilerstellung mit xhprof_enable()
2. Am Ende der Seite deaktivieren Sie die Profilerstellung mit xhprof_disable() und speichern die gesammelten Daten mit save_run()
3. Als nächstes übergeben wir mithilfe der PHP-Klasse firephp einen Link zu den Profilierungsdaten an den Client-Teil
4. In der Firebug-Konsole öffnen wir die benötigten Informationen
5. Wir freuen uns :)

Ich möchte auch sagen, dass es natürlich großartig ist, diese Funktionen manuell zu Ihren PHP-Skripten hinzuzufügen. Ich möchte aber, dass diese Informationen während der Entwicklung immer zur Hand sind und nicht auf den Produktionsservern landen. Wir lösen dieses Problem wie folgt:

In unseren Projekten wird in fast allen Skripten am Anfang eine Arbeitsdatei mit einem Klassenlader, Verbindungsfunktionen und anderen notwendigen Dingen verbunden. Aus diesem Grund haben wir die Aufnahme von Profiling in diese Datei aufgenommen. Und um den Debugging-Modus nach Belieben ein- und ausschalten zu können, haben wir eine Prüfung für die Konfigurationskonstante hinzugefügt und diese Prüfungen in einige Meta-Tags eingebettet, die beim Erstellen des Projekts automatisch entfernt werden. Gleiches gilt für das Deaktivieren der Profilerstellung und das Schreiben von Informationen in Header mit Firephp – diese Aufgaben werden durch eine Funktion gelöst, die am Ende jedes PHP-Skripts aufgerufen und ebenfalls in Meta-Tags verpackt wird. Es sieht ungefähr so ​​aus:

// Die folgenden Konstanten werden in die Anwendungskonfigurationsdatei geschrieben

/** Funktionsweise der Umgebung * */
define("APPLICATION_ENV" , "dev" ); // dev - Debugging | Pro - Produktion
/** Pfad zum Profiler */
define("XHPROF_ROOT" , __DIR__ . „/ExtProcs/debug/xhprof-0.9.2“);

/***************************************************************************************
* Als nächstes starten wir in der Datei, die am Anfang jedes Skripts geladen wird, die Profilerstellung
* DEV_START und DEV_END sind unsere Meta-Tags, alles dazwischen wird beim Zusammenbau ausgeschnitten
***************************************************************************************/

//-- DEV_START
//-- Im Debug-Modus verbinden wir Debug-Bibliotheken

// Firephp laden
require_once(__DIR__ . „/includes/ExtProcs/debug/firephp/FirePHP.class.php“);
//-- Laden Sie den Profiler
„/xhprof_lib/utils/xhprof_lib.php“);
require_once(XHPROF_ROOT. „/xhprof_lib/utils/xhprof_runs.php“);
// Profilerstellung mit den erforderlichen Flags initialisieren. Detaillierte Beschreibung der Flags
// finden Sie unter php.net/manual/ru/xhprof.constants.php
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
//-- DEV_END

// Nun, diese Funktion wird am Ende jedes Skripts aufgerufen
// Sein Aufruf ist ebenfalls in DEV_START und DEV_END eingeschlossen

/**
* Erstellen Sie einen Link zum Profilierungsergebnis und zeigen Sie ihn in der Konsole an
*/
Funktion dev_boot_Down() (
if (APPLICATION_ENV === "dev" ) (
// Initialisiere die Firephp-Instanz
$firephp = FirePHP::getInstance(true);
// Profiling deaktivieren und Daten speichern
$xhprof_data = xhprof_disable();
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing" );
// Einen Link zu den Profiling-Daten erstellen und in die Konsole schreiben
$link = "http://" . $_SERVER["HTTP_HOST" ] . "/includes/ExtProcs/debug/xhprof-0.9.2/xhprof_html/index.php?run=($run_id)&source=xhprof_testing\n";
$firephp->info($link, "profiling data" );
}
}

* Dieser Quellcode wurde mit Source Code Highlighter hervorgehoben.

Ich werde nicht näher auf die Installation dieser Erweiterungen eingehen, da hier alles einfach ist. Ich werde nur auf einige Aspekte des Setups eingehen. xhproof hat nur eine Konfigurationsvariable – xhprof.output_dir, die auf den Ordner verweist, in dem Profilierungsdaten gespeichert werden. Stellen Sie daher sicher, dass der Benutzer, unter dem die PHP-Skripte ausgeführt werden, Schreibrechte für das angegebene Verzeichnis hat. Schreiben Sie also so etwas in Ihre php.ini:

extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"

Es ist auch eine gute Idee, etwas wie dot oder Graphviz zu installieren, um Anrufdiagramme zu zeichnen. Ich habe Graphviz auf MacOS X.

Nachdem wir die oben beschriebenen Verfahren abgeschlossen hatten, konnten wir jederzeit die Profilierung aller unserer Skripte direkt im Browser öffnen und einsehen.

Bei der Anwendungsprofilierung handelt es sich um die Erfassung von Daten zur Ausführungsgeschwindigkeit verschiedener Programmabschnitte (Dateien und Funktionen). Es stehen viele PHP-Profilierungstools zur Verfügung, aber nicht alle Tools eignen sich für die Durchführung von Analysen direkt auf einer Produktionsseite.

XHProf und seine Abzweigung Tideways sind ein praktischer und einfacher Profiler, der effektiv Statistiken über den Betrieb der Anwendung sammeln kann, ohne die Geschwindigkeit Ihrer Anwendung (oder Ihrer Website) nahezu zu beeinträchtigen.

Warum Profilcode?

Wenn die Anwendung langsam zu arbeiten beginnt (lesen Sie „Die Website wurde langsamer“), können Sie mithilfe der Profilerstellung herausfinden, welcher Teil am langsamsten ist. Das Ergebnis der Profilerstellung ist in der Regel eine Liste der ausgeführten Funktionen mit Angabe ihrer Ausführungszeit.

Die Code-Profilierung sollte im Anwendungsoptimierungsprozess an erster Stelle stehen. Alles andere wäre Vermutung und höchstwahrscheinlich falsch. Man muss wissen, was genau Probleme und „Bremsen“ verursacht.

Profiling ist ein Verfahren zum Sammeln und Organisieren von Statistiken über die Ausführungszeit von Code. Dabei handelt es sich nicht um einen Prozess der Optimierung oder Programmänderung. Das Ergebnis dieses Prozesses ist in der Regel ein ausführlicher Bericht über Programmkomponenten und Funktionsleistungsstatistiken.

Genau dafür wurde die XHProf-Lösung entwickelt. Es ist so konzipiert, dass es auf echten Websites funktioniert. Die Hauptidee dieses Profilers besteht darin, die Anwendung so wenig wie möglich zu belasten und gleichzeitig alle erforderlichen Daten zur Betriebsgeschwindigkeit zu sammeln. Die Lösung wurde von Spezialisten von Facebook entwickelt.

Wie verbinde ich den PHP-Profiler automatisch?

Unsere Spezialisten haben hart gearbeitet und diesen Prozess vollständig automatisiert.
Sie müssen sich lediglich anmelden, im Reiter „Domains“ die gewünschte Domain auswählen, auf das Symbol „PHP.INI + PHP Profiler“ klicken und das Kontrollkästchen „Domain Profiler“ aktivieren.

Die Aktivierung dieser Funktion kann einige Zeit dauern, normalerweise nicht länger als 10 Minuten.

Für die PHP-Versionen 5.2, 5.3, 5.4, 5.5, 5.6, 7.0 verwenden wir den XHProf-Profiler, für die PHP-Versionen 7.1 und höher verwenden wir den Tideways-Profiler.

Nach der Aktivierung wird auf jeder von PHP verarbeiteten Seite Ihrer Website unten ein spezieller Block mit Links zur Berichtsdatei eingebaut (der Link sieht etwa so aus:

Domainname.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX&source=someapp)

Und so sieht die Berichtsdatei aus:

Die Tabelle enthält eine Liste der Funktionen, die innerhalb einer Seite ausgeführt wurden, mit zusätzlichen Informationen:

• Aufrufe – Anzahl und Prozentsatz der Funktionsaufrufe
• inkl. Wall Time – Ausführungszeit einer Funktion mit verschachtelten Funktionen
• Exkl. Wall Time – Funktionsausführungszeit ohne verschachtelte Funktionen
• inkl. CPU – Prozessorzeit mit verschachtelten Funktionen
• Exkl. CPU – Prozessorzeit ohne verschachtelte Funktionen
• inkl. MemUse – Speicherverbrauch mit verschachtelten Funktionen
• Exkl. MemUse – Speicherverbrauch ohne verschachtelte Funktionen
• inkl. PeakMemUse – maximaler Speicherverbrauch mit verschachtelten Funktionen
• Exkl. PeakMemUse – maximaler Speicherverbrauch ohne verschachtelte Funktionen

Es ist zu beachten, dass der unter Verwendung von Tidenwegen erstellte Bericht optisch geringfügig von diesem Bericht abweichen kann, sich das Wesentliche jedoch nicht ändert.

Grafische Berichte

Ressourcenintensive Abschnitte des Codes werden in Gelb (mittel) und Rot (am schwersten) hervorgehoben. Dies sind die Codeabschnitte, die im Vergleich zum Rest des Programms viele Ressourcen verbrauchen. Dies kann eine langsame Funktion oder mehrere Aufrufe einer schnellen Funktion sein. In unserem Beispiel sehen wir, dass die Funktion mysqli_multi_query() rot markiert ist, da sie am langsamsten läuft.

Aggregierte Berichte

Über die XHProf-Schnittstelle können Sie außerdem aggregierte Informationen aus mehreren Berichten gleichzeitig anzeigen. Dazu wird run_id durch Kommas getrennt übergeben:

Domain-name.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX,YYYYYYYYYY&source=someapp

Technische Eigenschaften

Die automatische Einbindung des Profilers wird mithilfe der Direktiven auto_append_file und auto_prepend_file implementiert, die zwei ausführbare PHP-Dateien verbinden:

— auto_append_file initialisiert das Statistikerfassungsobjekt und beginnt mit seiner Arbeit;

— auto_prepend_file vervollständigt die Sammlung von Statistiken und generiert eine Berichtsdatei mit Statistiken (im JSON-Format);

Wenn exit() oder die() aufgerufen wird, während Ihr Skript ausgeführt wird, wird auto_prepend_file nicht ausgeführt. Statistikdatei wird nicht generiert und ein Block mit Links zur Berichtsdatei wird am Ende der Seite nicht eingefügt.

1. Daher wird beim Zugriff auf jede von PHP verarbeitete Seite die Erstellung einer neuen Berichtsdatei ausgelöst. Wir empfehlen daher, den Profiler nach der Erfassung von Statistiken (normalerweise einige Stunden) zu deaktivieren, um ein Überlaufen des Festplattenkontingents zu vermeiden, das nach der Erstellung einer Datei erschöpft sein kann viele Berichte!
2. Wichtig: Der Profiler funktioniert nur, wenn die Site automatisch über einen Standardpfad mit dem Server verbunden ist (d. h. über das Hosting-Kontrollfeld). Andernfalls müssen Sie sich an den technischen Support von Hostland wenden, um den Profiler zu konfigurieren.
3. Im automatischen Modus stellt der Profiler nur eine Verbindung zum Hauptdomänennamen her; der Profiler wird nicht automatisch mit Unterdomänen verbunden.
4. Im automatischen Modus sammelt der Profiler Statistiken nur für Skripte mit der Erweiterung .php und .php5
5. Es ist nicht möglich, einen ununterbrochenen Betrieb der Site nach dem Anschließen des PHP-Profilers zu garantieren. Wenn die Site daher bei aktiviertem Profiler nicht ordnungsgemäß funktioniert, sollte dieser deaktiviert und die Profilerstellung auf andere Weise fortgesetzt werden.

Fassen wir es zusammen

Wir hoffen, dass dieses Tool Ihnen dabei hilft, Ihre Websites beim Hostland-Hosting noch schneller zu machen.

Der Artikel verwendete teilweise Materialien des Benutzers Den Golotyuk, die auf der Website veröffentlicht wurden

Es zeigte, wie man xdebug installiert und konfiguriert, und behandelte einige grundlegende Funktionen, wie z. B. die Verbesserung der Ausgabe der Funktion var_dump() oder das Drucken eines Call-Stack-Trace beim Empfang einer Fehlermeldung. Im zweiten Teil haben wir uns diese xdebug-Funktion als Tracing angesehen. Der Trace enthält alle Aufrufe von Funktionen und Methoden im Programm, Startzeit, optional Speichergröße, übergebene und zurückgegebene Parameter. Ein Trace-Protokoll kann Ihnen helfen, den Ausführungspfad eines komplexen Programms zu verstehen. Anstatt Debugging-Code in das Programm einzufügen, schalten Sie die Ablaufverfolgung bei Bedarf ein oder aus und verwenden dann Dienstprogramme wie grep oder Ihre eigenen PHP-Anwendungen, um die Protokolldatei zu analysieren.

In diesem Artikel befassen wir uns mit der Profilerstellung. Auf den ersten Blick ähnelt Profiling einem Tracing. Das Profiling-Protokoll ist nicht für Menschen gedacht und dient nicht dazu, den Ablauf eines Programms zu visualisieren, sondern liefert uns Daten zur statistischen Analyse eines laufenden Programms.

Erstellen eines Profiling-Protokolls

Nachfolgend finden Sie einen kurzen Auszug aus dem von xdebug generierten Profilierungsprotokoll:

fl=php:intern
fn=php::define
106 3

Fl=C:\www\drupal\includes\bootstrap.inc
fn=require_once::C:\www\drupal\includes\bootstrap.inc
1 648
cfn=php::define
Aufrufe=1 0 0
13 6
cfn=php::define
Aufrufe=1 0 0
18 4
cfn=php::define
Aufrufe=1 0 0
23 2

Wie Sie sehen, kann das Profiling-Protokoll nicht direkt gelesen werden. Wir werden zusätzliche Tools verwenden, um die gewonnenen Daten zu visualisieren und zu analysieren. Die Profilerstellung zeigt also, wie oft eine bestimmte Linie gestartet wurde und wie lange der Start gedauert hat.
Das Erstellen eines Profiling-Protokolls beeinträchtigt die Leistung erheblich, ähnlich wie das Erstellen eines Trace-Protokolls, da der Verlauf jeder Zeile beschrieben werden muss. Führen Sie die Profilerstellung daher wie beim Tracing nicht auf Produktionsservern aus. Es gibt jedoch Fälle, in denen die Profilerstellung auf einem Live-System ausgeführt werden muss. Seien Sie in diesem Fall vorsichtig, wenn Sie xdebug gleichzeitig mit anderen Zend-Erweiterungen wie Loadern, Optimierern oder Caches ausführen.
Damit xdebug mit der Aufzeichnung von Profilierungsprotokollen beginnen kann, fügen Sie Folgendes hinzu:

Bitte beachten Sie, dass Sie die Profilerstellung beim Start nicht durch Ausführen eines Befehls ausführen können.
Da das Profiling-Protokoll dazu gedacht ist, von Analyseprogrammen gelesen zu werden, gibt es keine zusätzlichen Einstellungen, die es Ihnen ermöglichen, zusätzliche Informationen anzuzeigen, wie es beim Trace-Protokoll der Fall ist. Es gibt jedoch einige Einstellungen, mit denen Sie die Profilerstellung konfigurieren können, ähnlich denen, die wir beim Einrichten der Nachverfolgung verwendet haben.
Erstens schreibt xdebug das Profiling-Protokoll standardmäßig in das Verzeichnis /tmp. Wenn Sie Windows verwenden, müssen Sie php.ini wie folgt reparieren:

xdebug.profiler_output_dir="c:\traces"

Standardmäßig überschreibt xdebug das vorhandene Profilierungsprotokoll. Sie können es so konfigurieren, dass es das vorhandene ergänzt, indem Sie den folgenden Befehl hinzufügen

in php.ini. Es gibt Fälle, in denen Sie nicht für alle Dateien ein Profiling-Protokoll erstellen möchten, gleichzeitig aber die Aktivierung des Profilings zur Laufzeit problematisch ist. Fügen Sie den Befehl hinzu, anstatt die Profilerstellung regelmäßig ein- und auszuschalten

xdebug.profiler_enable_trigger=Ein

in php.ini. Jetzt können Sie die Profilerstellung ein- und ausschalten, indem Sie einen speziellen GET- oder POST-Parameter XDEBUG_PROFILE an ein PHP-Skript übergeben. Dadurch wird die Profilerstellung nur für dieses PHP-Skript aktiviert. Es ist nicht erforderlich, den Wert dieses Parameters festzulegen. Denken Sie lediglich daran, diesen Parameter zur Adresse test.php?XDEBUG_PROFILE hinzuzufügen.

Name des Profilierungsprotokolls

Der Name, den xdebug dem Profiling-Protokoll standardmäßig zuweist, ist „cachegrind.out“. plus Prozesskennung. Genau wie beim Trace-Protokoll können Sie die Namen des Protokolls ändern, indem Sie die entsprechenden Einstellungen in php.ini hinzufügen. Parametername xdebug.profiler_output_name. Das Argument ist eine Zeichenfolge. die verschiedene Modifikatoren enthalten kann. Die wichtigsten sind unten aufgeführt:

• %p – Prozesskennung
• %r – Zufallszahl
• %u - Zeit
• %H – Wert von $_SERVER["HTTP_HOST"]
• %R – Wert von $_SERVER["REQUEST_URI"]
• %s – Name inklusive vollständigem Pfad, Schrägstriche werden in Unterstriche umgewandelt

Bitte beachten Sie, dass der Modifikator %s nur für xdebug.profiler_output_name verwendet wird. Wenn Sie den Namen des Profiling-Protokolls wissen möchten, können Sie die Funktion xdebug_get_profiler_filename() aufrufen.

Profiling-Protokollanalyse
Wie oben erwähnt, sind zur Analyse des Profiling-Protokolls zusätzliche Programme zur Datenvisualisierung erforderlich. Alle von xdebug erstellten Profilierungsprotokolle haben ein Format, das dem Cachegrind-Format ähnelt. Cachegrind ist ein Profiler, der Teil eines leistungsfähigeren Programms namens Valgrind ist, einem Software-Debugging- und Profiling-Programm für Linux. Cachegrind wurde entwickelt, um Statistiken zu Caches, Speichernutzung und Programmbefehlen zu analysieren. Ein weiteres Valgrind-Tool, Callgrind, zeichnet Anrufdiagramme. In Bezug auf PHP können wir diese Anwendung verwenden, um das Profiling-Protokoll zu visualisieren und zu analysieren.
Das Tool, das üblicherweise zum Analysieren des von xdebug generierten Profilierungsprotokolls verwendet wird, heißt . KCachegrind ist freie Software, die unter der GPL lizenziert ist (funktioniert nur auf Unix-Systemen). Es gibt jedoch ein einfaches Programm für Windows, das ebenfalls kostenlos ist. Schauen wir uns zunächst die Windows-Version an.

WinCacheGrind: Analyse von Profiling-Protokollen in Windows

Die aktuelle Version (zum Zeitpunkt des Verfassens dieses Artikels durch den Autor) von WinCachegrind ist 1.0.0.12. Diese Version stammt aus dem Jahr 2005, was bedeutet, dass WinCachegrind schon lange nicht mehr entwickelt wurde. Wenn man sich die Versionshinweise anschaut, schreiben die Autoren, dass das Programm Fehler aufweist, die zu manchmal seltsamen Verhaltensweisen führen.
Daher empfehle ich die Verwendung von KCachegrind, das auf Basis einer virtuellen Maschine auf der neuesten Linux-Distribution, zum Beispiel Ubuntu, gestartet wird (Anmerkung des Übersetzers, im Allgemeinen eine seltsame Empfehlung; in diesem Fall würde ich empfehlen, einfach Linux zu installieren und nicht einzuzäunen der Garten der virtuellen Maschinen). Es gibt eine große Anzahl virtueller Maschinen für Windows. Wenn es aus irgendeinem Grund nicht möglich ist, Unix oder eine virtuelle Maschine zu verwenden, können Sie WinCachegrind weiterhin für eine einfache Profiling-Protokollanalyse verwenden. Im Gegensatz zu KCachegrind zeichnet WinCachegrind keine Anrufdiagramme.
Die Installation von Wincachegrind ist äußerst einfach. Führen Sie das Installationsprogramm aus, klicken Sie auf die Schaltfläche zum Akzeptieren der Lizenz und die Installation ist abgeschlossen. Jetzt können Sie das Programm ausführen und eines der von xdebug erstellten Cachegrind-Profiling-Protokolle öffnen.

Durch Klicken auf die Uhr oder das Sigma-Symbol können Sie zwischen der Anzeige von Informationen in absoluten Werten und Prozentsätzen wechseln. Die Prozentanzeige zeigt an, wie viel Zeit als Prozentsatz der Gesamtzeit benötigt wird, um eine Funktion in einem bestimmten Block aufzurufen.
Zwei nützliche Einstellungen sind Profiler -> Schnelle Funktionen ausblenden und Profiler -> Bibliotheksfunktionen ausblenden. Der erste Schalter verbirgt Funktionen, deren Zeitbeitrag zur gesamten Programmausführungszeit unbedeutend ist.
Die zweite Einstellung, Profiler -> Bibliotheksfunktionen ausblenden, blendet in PHP integrierte Funktionen aus der allgemeinen Analyse aus. Wenn beide Einstellungen aktiviert sind, werden weniger Daten angezeigt, sodass Sie sich auf Bereiche Ihres Codes konzentrieren können, die optimiert werden müssen.
Das Hauptfenster enthält zwei Registerkarten: Zeile für Zeile und Gesamt. Auf beiden Registerkarten werden die gleichen Informationen angezeigt, aber auf der Registerkarte „Gesamt“ werden die Informationen für eine bessere Darstellung zusammengefasst. Die Eigenzeit zeigt die Laufzeit des Codes im aktuellen Block an, während die kumulative Zeit (Kum.) die Gesamtlaufzeit der Funktionen im angegebenen Block anzeigt.

KCacheGrind: Analyse von Profiling-Protokollen unter Unix

Die Unix-Version von KCachegrind bietet mehr Funktionalität als WinCachegrind. KCachegrind visualisiert die Daten und erstellt ein Anrufdiagramm.
Um es verwenden zu können, müssen Sie KCachegrind installieren. Aktuelle Version . Eine neuere Version (0.10.1) ist verfügbar, aber sie ist Teil des Valgrind-Pakets.
Verwenden Sie nach Möglichkeit einen Paketmanager, um das KCachegrind-Paket zu installieren. KCachegrind verwendet GraphViz zum Zeichnen von Aufrufdiagrammen. Daher müssen Sie auch das GraphViz-Paket installieren, wenn Ihr Paketmanager abhängige Pakete nicht automatisch installiert.
Wenn Sie das KCachegrind-Binärpaket nicht finden, müssen Sie KCachegrind selbst kompilieren. Führen Sie nach dem Herunterladen der Quellen Folgendes aus

./configure --prefix=/opt/kde3
machen
make installieren

Wie Sie sehen, müssen Sie den Pfad zur aktuellen Installation der KDE-Bibliothek angeben. Wenn Sie nicht wissen, wo sich die KDE-Bibliotheken auf Ihrem System befinden, verwenden Sie

um den Pfad zu den KDE-Bibliotheken anzuzeigen.
Nach der Installation können Sie KCacheGrind über die Befehlszeile ausführen

Die tabellarische Darstellung von Daten in KCachegrind ist WinCachegrind sehr ähnlich. Sie können auch zwischen absoluten und prozentualen Werten wechseln. Einige KCachegrind-Funktionen sind nicht für PHP konzipiert. Das Bild unten zeigt das Aufrufdiagramm des phpMyAdmin-Programms:

Wie Sie sehen, wurde die meiste Startzeit in common.inc.php verbracht. Der folgende Screenshot zeigt eine Visualisierung von Funktionsaufrufen in common.inc.php:

Dieser Codeblock führt zwei require_onces aus, was der Hälfte der Zeit entspricht, die für die Ausführung von common.inc.php benötigt wird. Durch Doppelklicken auf ein beliebiges Rechteck gelangen Sie tiefer in die Datenanalyse.

Codeoptimierung basierend auf Profiling-Daten

Erstellen Sie vor der Optimierung immer ein Profil Ihrer Anwendungen. Sie können selbst mit der Optimierung dort beginnen, wo Sie den Eindruck haben, dass diese Optimierung einen Effekt bringt, aber das ist nicht immer der Fall. Die Optimierung wirkt sich hauptsächlich nur in den Teilen aus, die im Ausführungsprozess die meiste Zeit in Anspruch nehmen.
Wenn Sie viele Kopien eines Programms gleichzeitig ausführen, müssen Sie möglicherweise dennoch den Teil Ihres Programms optimieren, der die meiste Ausführungszeit in Anspruch nimmt. In diesem Fall beschleunigt die Optimierung nicht die Bearbeitung einer einzelnen Anfrage, sondern ermöglicht es Ihrem Server, hohe Lasten zu bewältigen und gleichzeitig weniger Ressourcen für die Bearbeitung dieser Anfragen zu verbrauchen.
Beachten Sie bei der Betrachtung der Profiler-Laufdauer, dass absolute Werte weniger wichtig sind als relative Werte. Auf verschiedenen Systemen gemessen, können die absoluten Werte variieren. Bevor Sie jedoch mit der Optimierung Ihres Codes beginnen, sollten Sie Folgendes berücksichtigen.
Eine wichtige Regel bei der Optimierung besteht darin, die Anzahl der I/O-Vorgänge zu reduzieren. Einige E/A-Vorgänge sind im Vergleich zu Berechnungen sehr zeitaufwändig. Die Reduzierung solcher Vorgänge kann eine sehr effektive Möglichkeit sein, Ihr Programm zu beschleunigen. Das Entfernen eines I/O-Aufrufs kann eine effektivere Verbesserung bringen, als viele Stunden damit zu verbringen, den Code zu optimieren. Daher sollten Sie sich zunächst auf E/A-Vorgänge konzentrieren, bevor Sie mit dem Codieren beginnen.
Sie können vor der Optimierung auch die Anzahl Ihrer Server erhöhen. Sie können ein großes Modell kaufen, das Ihnen eine kleine Leistungssteigerung bringt. Die Entwicklungszeit ist teurer als der Preis eines neuen Servers. Und wenn Sie die Hardwaremenge erhöhen, können Sie sicher sein, dass Sie die Steigerung sofort erhalten, ohne dass sich dies auf den PHP-Code auswirkt. Wenn ein Entwickler ein oder zwei Tage damit verbringt, Code zu optimieren, kann man nie sagen, wie stark sich die Produktivität steigern wird. Und am Ende kann man nicht mehr sicher sein, dass die Optimierung keine Fehler mit sich bringt.
Das Konvertieren einiger Seiten in statische Seiten ist eine Möglichkeit, eine bessere Leistung zu erzielen. Nehmen wir an, es gibt eine Site mit viel Verkehr, auf der ein PHP-Skript die erste Seite für jede Anfrage erstellt und dabei Informationen aus einer Datenbank oder XML-Datei auswählt. Wenn sich die Daten auf einer Seite häufig genug ändern, können Sie eine statische Kopie davon neu erstellen. Wenn die Konvertierung in eine statische Ansicht für eine Seite nicht möglich ist (einige persönliche Informationen werden auf der Seite angezeigt), können Sie einige Blöcke in eine statische Ansicht konvertieren.
Eine weitere Optimierungsebene erfordert keine Änderung des PHP-Codes. Wie wir wissen, ist PHP eine interpretierte Sprache. Das bedeutet, dass seine Befehle zur Laufzeit in Zwischencode übersetzt werden. Die Übertragung wird jedes Mal wiederholt, wenn das Skript ausgeführt wird. Dies macht PHP langsamer im Vergleich zu Sprachen wie C oder Java, bei denen der Code nicht bei jeder Ausführung analysiert werden muss. Für PHP können Sie Zwischenrepräsentationscaches (siehe meine Übersetzung ...) verwenden, um Zwischencode zu speichern und wiederzuverwenden. Dies beschleunigt den Start und die Ausführung.
All dies bedeutet nicht, dass es keine Zeit und keinen Ort gibt, um PHP-Code zu optimieren. Einige Codeoptimierungen können die Leistung erheblich verbessern. Denken Sie jedoch immer daran, dass eine Änderung des Codes immer das Risiko birgt, dass zusätzliche Fehler und Sicherheitsprobleme entstehen. Denken Sie auch daran, dass die Optimierung Ihres Codes die Lesbarkeit beeinträchtigt.

Abschluss

Das Erstellen und Visualisieren eines Profiling-Protokolls ist eine der wichtigen Voraussetzungen für die Optimierung von PHP-Code. Sie müssen wissen, welche Stellen im Programm die meiste Zeit in Anspruch nehmen, und dort sollten Sie mit der Optimierung beginnen.
Im nächsten Artikel werden wir uns mit dem Debuggen mit xdebug befassen. xdebug bietet Ihnen die Möglichkeit, Remote-Debugging durchzuführen. Mit einem Client, der über diese Funktion verfügt, wie z. B. Eclipse PDT, können Sie Ihren Code debuggen, ohne ihn zu ändern, Haltepunkte festlegen, durch Codeabschnitte springen und sehen, wie und wo Variablen Werte ändern.

Eine PHP-Erweiterung namens Xdebug ist verfügbar, um die Profilerstellung von PHP-Anwendungen sowie das Laufzeit-Debugging zu unterstützen. Beim Ausführen des Profilers wird die Ausgabe in eine Datei in einem Binärformat namens „cachegrind“ geschrieben. Auf jeder Plattform stehen Anwendungen zur Analyse dieser Dateien zur Verfügung. Zur Durchführung dieser Profilerstellung sind keine Änderungen am Anwendungscode erforderlich.

Um die Profilerstellung zu aktivieren, installieren Sie die Erweiterung und passen Sie die php.ini-Einstellungen an. Einige Linux-Distributionen werden mit Standardpaketen geliefert (z. B. das php-xdebug-Paket von Ubuntu). Dies ermöglicht es uns, die Einstellungen statisch zu halten und den Profiler nur bei Bedarf zu aktivieren.

# php.ini-Einstellungen # Auf 1 setzen, um es für jede Anfrage zu aktivieren xdebug.profiler_enable = 0 # Lassen Sie uns einen GET/POST-Parameter verwenden, um den Profiler zu aktivieren xdebug.profiler_enable_trigger = 1 # Der GET/POST-Wert, den wir übergeben werden, ist leer für jeden Wert xdebug.profiler_enable_trigger_value = "" # Cachegrind-Dateien nach /tmp ausgeben, damit unser System sie später bereinigt xdebug.profiler_output_dir = "/tmp" xdebug.profiler_output_name = "cachegrind.out.%p"

Als nächstes verwenden Sie einen Web-Client, um eine Anfrage an die URL Ihrer Anwendung zu stellen, die Sie profilieren möchten, z. B.

Http://example.com/article/1?XDEBUG_PROFILE=1

Während die Seite verarbeitet wird, schreibt sie in eine Datei mit einem Namen wie

/tmp/cachegrind.out.12345

Standardmäßig ist die Zahl im Dateinamen die Prozess-ID, die sie geschrieben hat. Dies kann mit der Einstellung xdebug.profiler_output_name konfiguriert werden.

Beachten Sie, dass für jede ausgeführte PHP-Anfrage/jeden ausgeführten PHP-Prozess eine Datei geschrieben wird. Wenn Sie beispielsweise einen Formularbeitrag analysieren möchten, wird ein Profil für die GET-Anfrage geschrieben, um das HTML-Formular anzuzeigen. Der Parameter XDEBUG_PROFILE muss an die nachfolgende POST-Anfrage übergeben werden, um die zweite Anfrage zu analysieren, die das Formular verarbeitet. Daher ist es bei der Profilerstellung manchmal einfacher, Curl auszuführen, um ein Formular direkt zu posten.

Analysieren der Ausgabe

Sobald der Profilcache geschrieben ist, kann er von einer Anwendung wie Webgrind gelesen werden. PHPStorm, eine beliebte PHP-IDE, kann diese Profilierungsdaten ebenfalls anzeigen.

KCachegrind zeigt beispielsweise folgende Informationen an:

• Ausgeführte Funktionen
• Aufrufzeit, sowohl selbst als auch einschließlich nachfolgender Funktionsaufrufe
• Häufigkeit, mit der jede Funktion aufgerufen wird
• Rufen Sie Diagramme auf
• Links zum Quellcode

Wonach schauen

Offensichtlich ist die Leistungsoptimierung sehr spezifisch für die Anwendungsfälle jeder Anwendung. Im Allgemeinen ist es gut, nach Folgendem zu suchen:

• Wiederholte Aufrufe derselben Funktion, die Sie nicht erwarten würden, könnten für Funktionen, die Daten verarbeiten und abfragen, die besten Gelegenheiten für die Zwischenspeicherung Ihrer Anwendung sein.
• Langsam laufende Funktionen. Wo verbringt die Anwendung die meiste Zeit? Der beste Nutzen bei der Leistungsoptimierung besteht darin, sich auf die Teile der Anwendung zu konzentrieren, die die meiste Zeit in Anspruch nehmen.

Notiz: Xdebug und insbesondere seine Profilierungsfunktionen sind sehr ressourcenintensiv und verlangsamen die PHP-Ausführung. Es wird empfohlen, diese nicht in einer Produktionsserverumgebung auszuführen.