Profilierung von PHP-Code. Profiling PHP mit XHprof Analyse der Profiling-Log-Beschreibung

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 dem Tracing. Das Profiling-Protokoll ist nicht für Menschen bestimmt und dient nicht dazu, den Ablauf der Programmausführung zu visualisieren, sondern liefert uns Daten für statistische Analyse laufendes Programm.

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, ist dies nicht der Fall zusätzliche Einstellungen, die es Ihnen ermöglichen, zusätzliche Informationen anzuzeigen, wie im Fall eines Trace-Protokolls. 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, benötigen Sie zur Analyse das Profiling-Protokoll zusätzliche Programme zur Datenvisualisierung. 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 kostenlos Software Verfügbar unter GPL-Lizenz (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

Aktuelle Version(zum Zeitpunkt des Schreibens durch den Autor dieses Artikels) WinCachegrind – 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 ansieht, schreiben die Autoren, dass das Programm Fehler aufweist, die manchmal zu seltsamem Verhalten 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 die Verwendung von Unix oder nicht möglich ist virtuelle Maschine Aus welchem ​​Grund auch immer, Sie können 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 integrierte Funktionen aus PHP-Funktionen. 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 . Mehr eine neue Version(0.10.1) ist verfügbar, aber 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 der von 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 Gerät kaufen, das Ihnen eine kleine Produktivitätssteigerung beschert. 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 die Produktivität steigen 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 Website mit viel Verkehr, wo PHP-Skript erstellt für jede Anfrage eine erste Seite und wählt Informationen aus einer Datenbank oder XML-Datei aus. 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 dies nicht der richtige Zeitpunkt oder Ort ist, 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.

Letzte Aktualisierung: 12.01.2019

Veröffentlichung: 01.09.2016


Mit PhpStorm können Sie die Leistung Ihres PHP-Codes analysieren, indem Sie ihn profilieren. Durch Profiling können Sie Programmausführungsstatistiken sammeln: die Namen der ausgeführten Funktionen, wie oft jede Funktion ausgeführt wurde, die Ausführungszeit jeder Funktion, welche anderen Funktionen innerhalb jeder Funktion aufgerufen wurden usw.

Diese Informationen können Ihnen Hinweise darauf geben, wo Ihr Code verbessert werden kann.

Mal sehen, wie es funktioniert.

1. Voraussetzungen

PhpStorm IDE kann Profilierungsinformationen verwenden, die mit dem Xdebug-Tool gesammelt wurden. Diese Erweiterung muss auf Ihrem System installiert und konfiguriert werden. Zum Erhalten Weitere Informationen Weitere Informationen finden Sie im Xdebug-Installationshandbuch.

Wenn Sie Benutzer der wunderbaren tragbaren Serverplattform und der Open Server-Softwareumgebung sind, müssen Sie nichts tun – die Xdebug-Erweiterung ist bereits installiert und verbunden.

Aufmerksamkeit

Xdebug ist nicht mit IonCube kompatibel. IonCube ist ein Tool (Dienstprogramm) zum Schutz von in der Sprache geschriebener Software PHP-Programmierung. Deaktivieren Sie die IonCube-Erweiterung vollständig oder während Sie Xdebug verwenden. Ein weiteres mögliches Problem könnte sein, dass Xdebug standardmäßig auf Port 9000 konfiguriert ist, dem gleichen Port, der von Open Server verwendet wird. Um dieses Problem zu lösen, sollten Sie in einem der Fälle die Portnummer ändern.

Alle hier beschriebenen Aktionen wurden mit den korrekten erwarteten Ergebnissen unter der folgenden technologischen Umgebung reproduziert:

2. Aktivieren des Xdebug-Profilers

Die Profilerstellung erhöht den Mehraufwand beim Ausführen der Anwendung und generiert eine große Menge an Festplatteninformationen. Daher ist es am besten, den Xdebug-Profiler nur bei Bedarf zu aktivieren und unter normalen Umständen zu deaktivieren.

Xdebug wird über Anweisungen in der aktiven php.ini-Datei konfiguriert. Wenn Sie den Profiler aktivieren, müssen Sie die folgende Anweisung konfigurieren:

xdebug.profiler_output_dir = /path/to/store/snapshots

Der Wert der Direktive muss den Pfad angeben, der zum Speichern von Profilierungsdateien verwendet wird.

2.1. Global

Um den Xdebug-Profiler global zu aktivieren, müssen Sie die folgende Anweisung verwenden:

xdebug.profiler_enable = 1

Auf diese Weise wird die Profilerstellung jedes Mal durchgeführt, wenn ein Skript ausgeführt wird. Es ist sinnvoll, diese Option zum Aktivieren des Profilers nur in seltenen Fällen zu verwenden.

2.2. Verwendung zusätzlicher Dolmetscheroptionen

Aktivieren Sie den Profiler mit zusätzliche Parameter Interpreter im Fenster „Konfigurationen ausführen/debuggen“. Um es zu öffnen, verwenden Sie die folgenden Elemente im IDE-Hauptmenü:

Option (im Screenshot oben mit einer roten Umrandung markiert) Interpreter-Optionen (Interpreter-Optionen) des Befehlszeilenabschnitts ( Befehlszeile) sollte die folgende Zeile enthalten:

D xdebug.profiler_enable = 1

Mit dieser Option können Sie den Profiler für eine bestimmte Konfiguration und nicht auf globaler Ebene verwenden.

2.3. Verwendung spezieller GET/POST-Parameter oder einer Cookie-Datei

Für eine kontrolliertere Profilerstellung sollte die folgende Direktive verwendet werden:

xdebug.profiler_enable_trigger = 1

Wenn der Wert der Direktive auf 1 gesetzt ist, wird beim Ausführen eines Skripts mit einem GET/POST-Parameter oder Cookie namens XDEBUG_PROFILE die Profilerstellung unabhängig von der xdebug.profiler_enable-Einstellung durchgeführt.

Diese Option zum Aktivieren des Profilers ist die beliebteste.

3. Erfassung von Profiling-Protokollen

Um Profiling-Protokolle analysieren zu können, müssen diese zunächst erfasst werden.

3.1. Sammlung von Profiling-Protokollen für Webanwendungen

Um Webanwendungen zu profilieren, verwenden Sie den Xdebug-Profiler global oder starten und stoppen Sie ihn bei Bedarf. Öffnen Sie nach dem Einschalten des Profilers die Anwendung im Browser, um mit der Datenerfassung – Profilerstellungsprotokollen – zu beginnen.

Bei der Analyse von Leistungsproblemen ist die Verwendung von Bookmarklets oder Browsererweiterungen zum Debuggen ein sehr guter Ansatz, da Sie so durch die Anwendung navigieren und den Profiler nur dann starten können, wenn ein Leistungsproblem erkannt wird. Dadurch können Sie gezielt Profiling-Protokolle sammeln.

3.2. Sammlung von Profiling-Protokollen für CLI-Anwendungen und Komponententests

Um CLI-Anwendungen und Komponententests zu profilieren, verwenden Sie den Xdebug-Profiler global oder erstellen Sie eine separate Ausführungskonfiguration, um den Profiler über das Fenster „Ausführungs-/Debug-Konfigurationen“ zu aktivieren. Führen Sie dann die CLI-Anwendung oder Komponententests aus, um Profilierungsdaten zu sammeln.

Bei der Analyse von Leistungsproblemen in Unit-Tests besteht ein guter Ansatz darin, eine separate Konfiguration zu erstellen, um nur diejenigen Unit-Tests auszuführen, bei denen der Verdacht besteht, dass sie Leistungsprobleme haben. Dadurch können Sie gezielt Profiling-Protokolle sammeln.

4. Analyse der Profiling-Protokollbeschreibung

Schauen wir uns das Profiling-Protokoll genauer an.

4.1. Öffnen des Profiling-Protokolls

Um das Profiling-Protokoll zu öffnen, verwenden Sie die folgenden Elemente im IDE-Hauptmenü: .

Wenn Sie Benutzer der wunderbaren tragbaren Serverplattform Open Server sind, können Sie das Profilierungsprotokoll auch mit dem plattformübergreifenden Tool Webgrind anzeigen. Es kann über die folgenden Open Server-Hauptmenüpunkte gefunden werden [Erweitert → PHP-Profiler].

Profilierungsprotokolle werden gemäß der konfigurierten xdebug.profiler_output_dir-Direktive in einem Ordner gespeichert. Der generierte Dateiname beginnt immer mit „cachegrind.out“. und endet entweder mit der PHP- oder Webserver-Prozess-ID oder dem crc32-Hash des Verzeichnisses, in dem sich das profilierte Skript befindet.


4.2. Registerkarte „Ausführungsstatistik“.

Auf der Registerkarte „Ausführungsstatistik“ können Sie zusammenfassende Informationen zu den Ausführungsmetriken jeder aufgerufenen Funktion untersuchen. Sie können alle Dateien, Funktionsaufrufe, wie oft sie aufgerufen wurden und die Ausführungszeit (absolut und relativ) jeder Funktion sehen.

Das obere Raster zeigt verschiedene Metriken an:

  • Eigene Zeit – die Zeit, die eine Funktion mit der Ausführung ihres Codes verbringt (ohne Berücksichtigung von Aufrufen anderer Funktionen).

Im unteren Raster werden zwei Registerkarten angezeigt: Aufgerufene – die Funktionen, die das Skript hier aufruft, und Aufrufer – wo das Skript aufgerufen wurde. Verschiedene Kennzahlen können Sie hier einsehen:

  • Zeit – Gesamtausführungszeit.
  • Anrufe – Anzahl der Anrufe.

Funktionen mit langer Ausführungszeit oder vielen Aufrufen bedürfen auf jeden Fall einer Prüfung.

4.3. Registerkarte „Anrufbaum“.

Auf der Registerkarte „Aufrufbaum“ werden die Ausführungspfade Ihres Codes angezeigt. Hier können Sie mehr sehen genaue Informationüber die Ausführungszeit jeder Funktion usw.

Das obere Raster zeigt Aufrufbäume (welche Funktionen in anderen Funktionen aufgerufen werden) und andere Metriken an:

  • Aufrufbar (genannt Datei) – die Datei, die ausgeführt wurde.
  • Zeit – Gesamtausführungszeit.
  • Anrufe – Anzahl der Anrufe.

Im unteren Raster werden zwei Registerkarten angezeigt: Aufgerufene – Funktionen, die hier aufgerufen werden, und Aufrufer – wo die Funktion aufgerufen wird. Verschiedene Kennzahlen können Sie hier einsehen:

  • Callable (genannt Funktion) – eine Funktion, die ausgeführt wurde.
  • Zeit – Gesamtausführungszeit.
  • Anrufe – Anzahl der Anrufe.

Kontrollfragen

  1. Warum werden PHP-Anwendungen profiliert?
  2. Wie viele Möglichkeiten gibt es, den Xdebug-Profiler zu aktivieren?
  3. Wie geht man bei der Profilierung von CLI-Anwendungen und Unit-Tests am besten vor?
  4. Mit welchen Tools können Profiling-Protokolle analysiert werden?
  5. Auf welche Kennzahlen sollten Sie bei der Analyse eines Profiling-Protokolls zuerst achten?

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

XHProf- ein supereinfacher Profiler, der Statistiken direkt sammelt, während die Anwendung fast ohne Overhead ausgeführt wird.

Warum Profil?

Wenn eine Anwendung langsam läuft, können Sie mithilfe der Profilerstellung herausfinden, welcher Teil langsam ist. Das Ergebnis der Profilierung ist in der Regel eine Liste der ausgeführten Funktionen und deren Ausführungszeit.

Die Profilerstellung sollte vor jeder Anwendungsoptimierung erfolgen. Andernfalls werden Sie sich von Vermutungen leiten lassen. Höchstwahrscheinlich falsch.

Xdebug-Problem

Xdebug ist eine leistungsstarke Lösung für PHP. Aber die Xdebug-Plattform selbst ist so schwer, dass sie kann nicht auf Live-Sites verwendet werden. XDebug belastet die Serverressourcen erheblich und verlangsamt die Anwendung.

Andererseits können Probleme auf einer Live-Site völlig anders sein als in einer Entwicklungsumgebung. Eine Profilerstellung nur auf Entwicklercomputern zeigt nur einen Teil der Probleme.

Deshalb wurde die Lösung entwickelt XHprof. Es ist für die Verwendung in laufenden Anwendungen vorgesehen. 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 den Jungs von Facebook entwickelt und wird von neuen PHP-Versionen unterstützt.

XHProf

Installation

Unter Debian befindet sich XHprof in SID-Paketen, also: apt-get install xhprof

Sie können XHprof auch selbst erstellen.

Profilerstellung aktivieren

Nehmen wir an, wir haben ein Skript mit dem folgenden Code:

ausführen();

Führen wir die Profilerstellung mit XHprof durch. Dazu benötigen Sie auf dieser Seite:

  1. Aktivieren Sie den Profiler gleich zu Beginn.
  2. Stoppen Sie ganz am Ende des Programms den Profiler und speichern Sie die empfangenen Daten.

Es wird so aussehen:

# Initialisieren Sie den Profilerxhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); # Führen Sie das Programm aus, nachdem Sie den Profiler eingeschaltet haben ausführen(); # Stoppen Sie den Profiler nach der Ausführung des Programms$xhprof_data = xhprof_disable();

# Speichern Sie das Profilierungsergebnis in der Variablen $xhprof_data

  • Funktion xhprof_enable() akzeptiert Flags als Argumente. XHPROF_FLAGS_CPU zum Aufzeichnen von Prozessorstatistiken, XHPROF_FLAGS_MEMORY für Speicher, XHPROF_FLAGS_NO_BUILTINS zum Ignorieren integrierter Funktionen.
  • xhprof_disable() schaltet den Profiler aus und gibt die gesammelten Statistiken zurück.

Berichte

Generation

Die gesammelten Daten können in der XHprof-Schnittstelle analysiert werden, um Berichte zu erstellen. Dazu müssen Sie die XHprof-Quellen herunterladen: cd /var/www; wget http://pecl.php.net/get/xhprof-0.9.4.tgz gzip -d xhprof-0.9.4.tgz tar -xvf xhprof-0.9.4.tar

Danach müssen Sie Änderungen am Skript vornehmen:

include_once "/var/www/xhprof-0.9.4/xhprof_lib/utils/xhprof_lib.php"; include_once "/var/www/xhprof-0.9.4/xhprof_lib/utils/xhprof_runs.php"; $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "test");

# Neuer Code speichert den Bericht zur Verwendung in der GUI

Schnittstelle für Berichte

Um den Bericht anzuzeigen, müssen Sie den virtuellen Host im Ordner /var/www/xhprof-0.9.4/xhprof_html konfigurieren. Zum Beispiel in Nginx:

Server ( server_name xh..9.4/xhprof_html; index index.php; Standort ~* \.(php)$ ( fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; ) ) nginx -s neu laden

Danach erscheint eine Liste mit Berichten:

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 ist die Ausführungszeit einer Funktion 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.

Grafische Berichte

Um einen grafischen Bericht zu erstellen, stellen Sie sicher, dass Sie graphviz installiert haben: apt-get install graphviz

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 die Funktion str_replace() Rot markiert wegen 262 Anrufen.

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: http://xh..php?run= 53a894f6d5d9b,53a894fcf126e&source=test

TL;DR

Verwenden Sie XHprof, um PHP direkt in der Produktion zu profilieren.

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 über einen sehr langen Zeitraum 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.

Profilierung von PHP-Code

Früher oder später wird jeder von uns mit Legacy-Code und dessen Optimierung konfrontiert. In einer solchen Situation sind ein Debugger und ein Profiler die besten Assistenten des Programmierers. Für diejenigen, die mit PHP arbeiten, gibt es dank Derick Rethans ein gutes Tool – xDebug. Selbst in RuNet gibt es viele Informationen zu xDebug, daher wird dieser Artikel nicht darauf eingehen.

Als ich auf die Erwähnung eines Profilers für PHP stieß, dachte ich sofort an xDebug (die proprietären Tools von Zend hatte ich schon lange vergessen), aber dieses Mal habe ich mich geirrt – wir werden über XHProf sprechen.
XHProf

Dieser Profiler wurde speziell für Facebook entwickelt und sein Quellcode wurde im März 2009 veröffentlicht.

Die Installation verlief recht schnell und reibungslos.
wget pecl.php.net/get/xhprof-0.9.2.tgz
tar xvf xhprof-0.9.2.tgz
cd xhprof-0.9.2/extension/
phpize
./configure && make && make install
cd /usr/local/etc/php.d/
vim xhprof.ini
cd /usr/local/
vim header.php
vimfooter.php
vim etc/php.ini
/etc/init.d/php-fpm neu starten
cp vhost.conf.template prof.my.conf
sed -i s/site/prof/ prof.my.conf
vim prof.my.conf
/etc/init.d/nginx neu starten

Lassen Sie uns die genannten Konfigurationen analysieren

Xhprof.ini
extension=/usr/local/lib/php/extensions/no-debug-non-zts-20090626/xhprof.so
xhprof.output_dir="/home/max/www/profile/"

Prof.my.conf – Nginx-Konfiguration – die Standardkonfiguration.

Server (
Hören Sie 80;
Servername prof.my;
Zeichensatz utf8;

Root /usr/local/src/xhprof-0.9.2/xhprof_html ;
Standort/(
index index.php;
}

Standort ~ \.php$ (
fastcgi_pass 127.0.0.1:12000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/local/src/xhprof-0.9.2/xhprof_html/$fastcgi_script_name;
fastcgi_params einschließen;

In /usr/local/src/xhprof-0.9.2/xhprof_html gibt es PHP-Quellen, die eine gute WEBGUI für den Profiler erstellen.

Also zu den beiden Hauptdateien:

Header.php


include_once "/usr/local/src/xhprof-0.9.2/xhprof_lib/utils/xhprof_lib.php";
include_once "/usr/local/src/xhprof-0.9.2/xhprof_lib/utils/xhprof_runs.php";
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
}

Footer.php
if(isset($_COOKIE["xhprof"]))(
if (extension_loaded("xhprof")) (
$profiler_namespace = "myapp"; // Namespace für Ihre Anwendung
$xhprof_data = xhprof_disable();
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, $profiler_namespace);

// URL zu den XHProf-UI-Bibliotheken (Hostnamen und Pfad ändern)
$profiler_url = sprintf("http://prof.my/index.php?run=%s&source=%s", $run_id, $profiler_namespace);
Echo<<Profiler-Ausgabe
AUS;
}
}

Jetzt führen wir ein beliebiges PHP-Skript über das Web aus und sehen in der oberen linken Ecke einen Link zur Profiler-Ausgabe – genau dafür wurde der Host prof.my erstellt

Bitte beachten Sie, dass ich die Cookie-Prüfung verwende! Mit einer solchen Prüfung können Sie den Profiler sicher auf einem Produktionsserver verwenden – bei echten Daten und echter Auslastung.

Die Profiler-Weboberfläche zeigt Schilder mit Informationen zu jeder Funktion an und meldet die folgenden Informationen:

  • Anzahl der Aufrufe jeder Funktion
  • Wall-Time, Zeit, die für die Ausführung von Funktionen aufgewendet wird (einschließlich Warten auf Antworten von Sockets, Dateisystem usw.).
  • CPU-Zeit, Zeit, die für die Ausführung von Funktionen aufgewendet wird (ohne Warten auf Antworten von Sockets, Dateisystem usw.).
  • Speichernutzung
  • Spitzenspeichernutzung

Es ist möglich, die Tabelle nach jedem der Parameter zu sortieren

Die Informationen zu jeder Funktion sind in zwei weitere Typen unterteilt: Inklusive und Exklusive. „Inclusive“ umfasst die von untergeordneten Anrufen verwendeten Ziffern, während „Exclusive“ sie nicht umfasst. Es ist auch möglich, auf den Namen einer Funktion zu klicken, um nur Informationen über sie und die Funktionen anzuzeigen, von denen sie aufgerufen wurde und die von ihr aufgerufen wurden.

Wenn GraphViz auf dem System installiert ist, erstellt der Profiler ein Anrufdiagramm für Sie.

P.S. Ohne mit Traditionen zu brechen: Dies ist mein erster Beitrag auf Habré.

UPD: in PHP neu gepostet.

mob_info