Performance-Profiling mit Blackfire und XHProf: Engpässe finden

1. Warum Performance-Profiling nötig ist

Performance-Profiling ist der systematische Versuch herauszufinden, wohin die Laufzeit einer PHP-Anwendung tatsächlich fließt, statt es anhand von Vermutungen zu erraten. Ohne Messung landen Optimierungsversuche fast immer an der falschen Stelle: Ein Entwickler optimiert eine Funktion, die in der Praxis nur einen Bruchteil der Gesamtzeit ausmacht, während der eigentliche Engpass unangetastet bleibt. Erst ein belastbares Performance-Profiling zeigt, welche Funktionsaufrufe wie viel Zeit, CPU-Last oder Speicher verbrauchen, und macht Optimierung dadurch zu einer datengetriebenen statt einer intuitiven Übung.

Grundsätzlich unterscheidet man zwei Ansätze für Performance-Profiling. Sampling-Profiler nehmen in festen Intervallen, etwa alle Millisekunde, eine Stichprobe des aktuellen Call-Stacks. Aus vielen solchen Stichproben ergibt sich statistisch, welche Funktionen häufig auf dem Stack liegen und damit vermutlich viel Zeit beanspruchen. Der Overhead ist gering, weil zwischen den Stichproben keinerlei Instrumentierung aktiv ist, dafür bleibt das Ergebnis eine Näherung: sehr kurze Funktionsaufrufe können zwischen zwei Stichproben vollständig verschwinden.

Instrumentierungs-Profiler wie XHProf und Blackfires Probe gehen den entgegengesetzten Weg: Jeder einzelne Funktionsaufruf wird beim Betreten und Verlassen gemessen, wodurch exakte Aufrufzahlen, Zeiten und teils Speicherverbrauch pro Funktion entstehen. Der Preis dafür ist ein spürbarer Overhead, der die Laufzeit während des Profilings um ein Vielfaches erhöhen kann. Das ist der Grund, warum Performance-Profiling mit diesen Werkzeugen typischerweise gezielt für einzelne Requests oder Skript-Läufe aktiviert wird und nicht dauerhaft in der Produktion mitläuft.

2. XHProf Grundlagen: Extension, API und Rohdaten

XHProf ist eine PHP-Extension, ursprünglich von Facebook veröffentlicht und heute in aktiv gepflegten Forks wie longxinh/xhprof für aktuelle PHP-Versionen verfügbar. Die Installation erfolgt über PECL oder durch manuelles Kompilieren gegen die vorhandene PHP-Version, anschließend wird die Extension über extension=xhprof.so in der php.ini aktiviert. Da XHProf sich direkt in die Zend-Engine einhängt, muss die Extension zur genauen PHP-Minor-Version passen, ein Punkt, der bei PHP-8.4-Umgebungen gelegentlich einen aktuellen Fork statt des Original-Repositories erfordert.

Die API ist bewusst minimal gehalten: xhprof_enable() startet die Instrumentierung für den aktuellen Request oder Skript-Lauf, optional mit Flags wie XHPROF_FLAGS_CPU für CPU-Zeit-Erfassung und XHPROF_FLAGS_MEMORY für Speicherverbrauch. xhprof_disable() beendet die Messung und liefert ein assoziatives Array zurück, in dem für jede beobachtete Funktion die Anzahl der Aufrufe sowie Wall Time, CPU Time und Speicherwerte hinterlegt sind, jeweils aufgeschlüsselt nach Aufrufer-Kontext.

Diese Rohdaten sind zunächst nur ein PHP-Array im Speicher und müssen selbst persistiert werden, etwa als serialisierte Datei oder als Datensatz in einer eigenen Datenbank, jeweils unter einer eindeutigen Run-ID. Erst danach lassen sie sich in einer Oberfläche wie dem klassischen tprofiler-UI oder einem moderneren Fork wie XHGui laden, um Callgraphs, Aufrufzahlen und Zeiten interaktiv zu untersuchen.

<?php

declare(strict_types=1);

// Enable instrumentation profiling with CPU and memory tracking.
// XHPROF_FLAGS_CPU and XHPROF_FLAGS_MEMORY add overhead but
// are required to interpret CPU time separately from wall time.
xhprof_enable(XHPROF_FLAGS_CPU | XHPROF_FLAGS_MEMORY);

// --- application code under test runs here ---
runOrderImportBatch();
// -----------------------------------------------

// Stop instrumentation and retrieve the raw call data as an array.
$rawData = xhprof_disable();

// Persist the raw data to disk with a unique run id so it can be
// loaded later by a UI (tprofiler, XHGui) or diffed against another run.
$runId = uniqid('', true);
$namespace = 'order_import';
$storageDir = '/var/xhprof-runs';

if (!is_dir($storageDir)) {
    mkdir($storageDir, 0755, true);
}

file_put_contents(
    sprintf('%s/%s.%s.xhprof', $storageDir, $runId, $namespace),
    serialize($rawData)
);

echo "Profiling run stored as {$runId}\n";

3. Blackfire Grundlagen: Probe, Agent und SaaS-Backend

Blackfire besteht aus drei klar getrennten Komponenten. Die Probe ist eine PHP-Extension, die ähnlich wie XHProf in die Zend-Engine eingreift und Rohdaten zu jedem Funktionsaufruf sammelt. Der Agent ist ein lokaler Daemon-Prozess auf demselben Host oder Container, der die Rohdaten von der Probe über einen Unix-Socket entgegennimmt, zwischenspeichert und weiterleitet. Das SaaS-Backend, wahlweise auch als selbst gehostete Enterprise-Variante, übernimmt die eigentliche Auswertung: Es baut aus den Rohdaten den Callgraph, berechnet Metriken und rendert die interaktive Oberfläche.

Ein typischer Profiling-Request läuft so ab: Der Entwickler löst die Messung aus, per Browser-Toolbar, über das Kommando blackfire curl oder mit einem gesetzten X-Blackfire-Query-Header. Die Probe erkennt den Trigger, aktiviert die Instrumentierung für genau diesen Request und schickt die gesammelten Rohdaten nach Abschluss an den lokalen Agent. Der Agent lädt die Daten zum Blackfire-Backend hoch, das daraus in wenigen Sekunden einen fertigen, teilbaren Profiling-Report erzeugt.

Im Unterschied zu XHProf entfällt bei diesem Ablauf jede manuelle Speicherung und jede eigene Oberfläche. Zusätzlich profiliert Blackfire nicht nur HTTP-Requests, sondern ebenso CLI-Skripte, Worker- und Queue-Prozesse, was das Performance-Profiling von Hintergrundjobs genauso einfach macht wie das einer einzelnen Webseite.

4. Callgraph-Analyse: Exclusive Time vs. Inclusive Time

Der Callgraph ist das zentrale Werkzeug jeder tiefergehenden Performance-Analyse, und sein Nutzen steht und fällt mit der Unterscheidung zwischen Exclusive Time und Inclusive Time. Exclusive Time, auch Self Time genannt, misst ausschließlich die Zeit, die im Rumpf einer Funktion selbst verbracht wird, ohne die Zeit ihrer Unterfunktionen. Inclusive Time dagegen summiert die gesamte Zeit vom Betreten bis zum Verlassen der Funktion, inklusive aller darunterliegenden Aufrufe.

Diese Unterscheidung entscheidet, wo ein echter Engpass liegt. Sortiert man nach Exclusive Time, findet man die Funktionen, die tatsächlich selbst rechnen, etwa Serialisierung, reguläre Ausdrücke oder Array-Operationen. Sortiert man stattdessen nach Inclusive Time, findet man teure Teilbäume im Aufruf, also Funktionen, die selbst kaum Zeit verbrauchen, aber teure Funktionen darunter aufrufen. Eine Funktion mit hoher Inclusive Time und niedriger Exclusive Time ist ein reiner Durchlaufposten, der Engpass liegt weiter unten im Baum.

Praktisch zeigt sich das etwa bei einer Repository-Methode, deren Exclusive Time nahe null liegt, deren Inclusive Time aber neunzig Prozent der Gesamtzeit eines Requests ausmacht. Eine Optimierung dieser Methode selbst bringt nichts, der Callgraph muss weiter aufgeklappt werden, bis die tatsächliche Datenbankabfrage oder der teure Serializer sichtbar wird. Ohne die getrennte Betrachtung von Exclusive und Inclusive Time bleibt jedes Performance-Profiling oberflächlich.

5. Wall Time, CPU Time und I/O Wait interpretieren

Neben dem Callgraph liefert gutes Performance-Profiling drei getrennte Zeit-Metriken: Wall Time, CPU Time und die daraus ableitbare I/O-Wartezeit. Wall Time ist die tatsächlich verstrichene Uhrzeit vom Start bis zum Ende eines Aufrufs. CPU Time ist die Zeit, die der Prozessor in diesem Zeitraum tatsächlich mit Rechnen für diesen Aufruf verbracht hat. Die Differenz aus beiden Werten ist die Wartezeit, während der der Prozess blockiert war, ohne selbst zu rechnen.

Eine Funktion mit hoher Wall Time, aber niedriger CPU Time wartet, sie rechnet nicht. Das deutet auf Netzwerklatenz, eine langsame Datenbankabfrage, blockierendes Datei-I/O oder Lock-Contention hin, nicht auf einen ineffizienten Algorithmus. Der richtige Hebel ist hier keine Code-Optimierung, sondern das Reduzieren von Round-Trips, Caching oder Parallelisierung. Umgekehrt zeigt eine Funktion mit hoher CPU Time einen echten Rechenaufwand, der nur durch einen besseren Algorithmus oder weniger Arbeit pro Aufruf sinkt.

XHProf liefert Wall Time standardmäßig, CPU Time nur mit gesetztem XHPROF_FLAGS_CPU-Flag, weil die Erfassung zusätzlichen Overhead verursacht. Blackfire trennt beide Werte automatisch in seiner Timeline-Ansicht und kennzeichnet Wartezeit explizit als eigenen Balken, was die Interpretation ohne manuelle Berechnung erlaubt und das Performance-Profiling deutlich beschleunigt.

6. Blackfire CLI und automatisierte Assertions

Die Blackfire-CLI macht Performance-Profiling scriptbar und damit automatisierbar. Befehle wie blackfire run php skript.php oder blackfire curl url lösen ein Profiling ohne Browser-Interaktion aus, direkt aus einem Terminal oder einer Build-Pipeline heraus. Das erlaubt, einen kritischen Pfad einer Anwendung bei jedem Build automatisch zu profilen, statt Performance nur gelegentlich manuell zu prüfen.

Die eigentliche Stärke zeigt sich in der Datei .blackfire.yml, in der Szenarien und Assertions definiert werden. Eine Assertion wie main.wall_time < 200ms oder main.peak_memory < 64mb prüft nach jedem Profiling-Lauf automatisch, ob ein definierter Schwellwert überschritten wurde. blackfire run gibt bei verletzter Assertion einen Exit-Code ungleich null zurück, wodurch sich Performance-Regressionen direkt in der CI-Pipeline blockieren lassen, bevor sie in den Hauptzweig gelangen.

In der Praxis etabliert sich dabei ein Referenz-Workflow: Ein Baseline-Lauf auf dem Hauptzweig liefert die Vergleichswerte, jeder weitere Lauf auf einem Feature-Branch wird automatisch gegen diese Referenz verglichen. Blackfire markiert dann genau die Funktionen, die im Vergleich zur Referenz langsamer geworden sind, wodurch Performance-Regressionen auf Funktionsebene sichtbar werden, nicht nur als vage Gesamtzeit-Abweichung.

# Trigger a profiling run against the local dev environment,
# without opening a browser, directly from the CI job.
blackfire run --samples=1 php artisan orders:import --file=sample.csv

# Profile a single HTTP endpoint through curl instead of a real client.
blackfire curl https://staging.example.com/api/orders

# Exit code is non-zero if any assertion in .blackfire.yml fails,
# so this line alone can gate a merge in a CI pipeline.
echo "Blackfire exit code: $?"

# .blackfire.yml
# Defines automated performance assertions checked after every run.
tests:
  "Order import stays within performance budget":
    path: "/api/orders/import"
    assertions:
      - "main.wall_time < 250ms"
      - "main.cpu_time < 180ms"
      - "main.peak_memory < 96mb"
      - "sql.queries.count < 15"

  "No N+1 query pattern on product listing":
    path: "/catalog/products"
    assertions:
      - "metrics.sql.queries.count < 10"
      - "main.wall_time < 150ms"

7. XHProf standalone einrichten und Läufe diffen

Da XHProf keine eingebaute Persistenz mitbringt, muss eine eigene Speicher-Schicht ergänzt werden, um Performance-Profiling über die Zeit auswertbar zu machen. Klassisch implementiert man dafür ein einfaches Speicher-Interface, das die von xhprof_disable() gelieferten Rohdaten serialisiert und unter einer eindeutigen Kombination aus Run-ID, Namespace und Zeitstempel ablegt, wahlweise im Dateisystem oder in einer eigenen Datenbanktabelle.

Der eigentliche Mehrwert entsteht beim Diffing zweier Läufe: Man lädt die Rohdaten zweier Profiling-Durchläufe, etwa vor und nach einem Deployment, und vergleicht für jede in beiden Läufen vorkommende Funktion die Differenz von Wall Time und Exclusive Time. Sortiert man das Ergebnis absteigend nach der Differenz, erscheinen die Funktionen ganz oben, die zwischen den beiden Läufen am stärksten langsamer geworden sind, das manuelle Äquivalent zu Blackfires automatischem Referenzvergleich.

In der Praxis nutzt kaum noch jemand das originale tprofiler-UI, weil dessen alter Code auf aktuellen PHP-Versionen nicht mehr lauffähig ist. Etablierte Forks wie XHGui bringen stattdessen eine moderne, datenbankgestützte Speicherung und Weboberfläche mit eingebauter Diff-Funktion mit, wodurch der manuelle Aufwand für Performance-Profiling mit XHProf spürbar sinkt.

<?php

declare(strict_types=1);

/**
 * Load two persisted XHProf raw data arrays and diff them by
 * wall time and exclusive time, to spot regressions manually
 * without a dedicated UI.
 */
function loadRun(string $path): array
{
    return unserialize(file_get_contents($path), ['allowed_classes' => false]);
}

$before = loadRun('/var/xhprof-runs/before-deploy.order_import.xhprof');
$after  = loadRun('/var/xhprof-runs/after-deploy.order_import.xhprof');

$diffs = [];

foreach ($after as $function => $metrics) {
    if (!isset($before[$function])) {
        continue; // function did not exist in the baseline run
    }

    $wallDelta = $metrics['wt'] - $before[$function]['wt'];
    $exclDelta = ($metrics['wt'] - ($metrics['ct'] ?? 0))
        - ($before[$function]['wt'] - ($before[$function]['ct'] ?? 0));

    $diffs[$function] = [
        'wall_delta_us' => $wallDelta,
        'exclusive_delta_us' => $exclDelta,
    ];
}

// Sort by wall time delta descending: biggest regressions first.
uasort($diffs, static fn (array $a, array $b): int => $b['wall_delta_us'] <=> $a['wall_delta_us']);

foreach (array_slice($diffs, 0, 10, true) as $function => $delta) {
    printf("%-40s %+8d us wall  %+8d us exclusive\n", $function, $delta['wall_delta_us'], $delta['exclusive_delta_us']);
}

8. Flame Graphs lesen und erzeugen

Ein Flame Graph macht einen Callgraph auf einen Blick lesbar, ohne Tabellen mit Zahlen durchsuchen zu müssen. Auf der X-Achse liegt nicht die zeitliche Abfolge, sondern die Häufigkeit beziehungsweise der Zeitanteil eines Aufrufpfads, auf der Y-Achse die Tiefe des Call-Stacks. Die Breite jeder Box ist proportional zur verbrauchten Zeit, wodurch die breitesten Boxen sofort als größte Zeitfresser ins Auge fallen.

XHProf liefert keine direkt flame-graph-kompatiblen Daten, die Rohdaten müssen zunächst in das gefaltete Stack-Format konvertiert werden, das Brendan Gregg's flamegraph.pl erwartet: eine Zeile pro Aufrufpfad mit Semikolon-getrennten Funktionsnamen und der zugehörigen Zeit. Dafür existieren fertige Konvertierungsskripte, die die verschachtelten XHProf-Callgraphs in dieses flache Format übersetzen. Blackfire rendert stattdessen einen interaktiven Callgraph und eine Timeline-Ansicht, die dieselbe Information anders, aber ebenfalls visuell aufbereitet darstellt.

Beim Lesen eines Flame Graphs zählt vor allem die Breite, nicht die Höhe: Ein breites Plateau nahe der Spitze zeigt eine Blattfunktion mit hoher Exclusive Time, also einen echten Engpass, der im Performance-Profiling zuerst angegangen werden sollte. Ein hoher, aber schmaler Turm zeigt dagegen tiefe, aber insgesamt günstige Rekursion, die selten der eigentliche Performance-Killer ist.

# Convert a persisted XHProf run into the folded-stack format that
# Brendan Gregg's FlameGraph toolkit expects, then render an SVG.

php convert-xhprof-to-folded.php /var/xhprof-runs/run.order_import.xhprof \
  > /tmp/order_import.folded

# stackcollapse step is already done by the converter above,
# flamegraph.pl only needs the folded format as input.
flamegraph.pl /tmp/order_import.folded > /tmp/order_import.svg

echo "Flame graph written to /tmp/order_import.svg"

9. Praxisvergleich: Wann Blackfire, wann XHProf

Blackfire spielt seine Stärken dort aus, wo Performance-Profiling zur Teamaufgabe wird. Geteilte Profile mit Kommentaren, automatisierte Assertions in der CI-Pipeline und die Möglichkeit, nicht nur HTTP-Requests, sondern auch CLI-Skripte und Worker-Prozesse ohne Zusatzaufwand zu profilen, sprechen für den Managed-Service-Ansatz, allerdings gegen laufende Lizenzkosten und eine Abhängigkeit von einem externen Anbieter.

XHProf punktet dort, wo volle Kontrolle und keine externen Abhängigkeiten wichtiger sind als Komfort. Es ist quelloffen, kostenlos, und alle Profiling-Daten bleiben vollständig in der eigenen Infrastruktur, ein relevanter Punkt für Umgebungen mit strengen Compliance-Anforderungen. Der Preis dafür ist eigener Wartungsaufwand für Speicherung, Oberfläche und Diff-Tooling, da die Werkzeuge rund um XHProf selbst gepflegt werden müssen.

In der Praxis schließen sich beide Werkzeuge nicht aus. XHProf eignet sich für schnelles, lokales Performance-Profiling während der Entwicklung, ganz ohne Account oder Netzwerkabhängigkeit. Blackfire übernimmt die teamweite, in CI und Staging integrierte, kontinuierliche Regressionserkennung vor jedem Produktions-Deployment. Viele Teams nutzen beide parallel: XHProf für die schnelle Iteration am eigenen Rechner, Blackfire als automatisiertes Gate vor dem nächsten Release.

In der Praxis ist keines der beiden Kriterien allein entscheidend. Ein Team mit strengen Compliance-Vorgaben und eigener Ops-Kapazität wird oft zu XHProf tendieren, ein Team, das schnelle Ergebnisse ohne eigenen Wartungsaufwand sucht, zu Blackfire. Beide Werkzeuge messen letztlich dasselbe zugrunde liegende Modell aus Aufrufzahlen, Zeiten und Speicher, sie unterscheiden sich vor allem in Komfort, Automatisierungsgrad und Betriebsmodell.

10. Zusammenfassung

Performance-Profiling ist kein Werkzeug für Ausnahmefälle, sondern die einzige verlässliche Methode, um Engpässe in PHP-Anwendungen datenbasiert statt anhand von Vermutungen zu finden. Sampling-Profiler liefern schnelle, überblicksartige Hinweise mit geringem Overhead, Instrumentierungs-Profiler wie XHProf und Blackfire liefern exakte Aufrufzahlen, Exclusive- und Inclusive-Zeiten sowie getrennte Wall-Time- und CPU-Time-Werte, mit denen sich Rechenlast klar von Wartezeit unterscheiden lässt.

Blackfire bringt Performance-Profiling als Managed-Service mit Agent, SaaS-Backend, automatisierten Assertions und Referenzvergleichen direkt in die CI-Pipeline. XHProf bietet dieselbe Tiefe als quelloffene Extension ohne externe Abhängigkeit, verlangt dafür aber eigene Speicherung, Diff-Tooling und gegebenenfalls Flame-Graph-Konvertierung. Welches Werkzeug den Vorzug bekommt, hängt weniger von der technischen Tiefe als von Teamgröße, Compliance-Anforderungen und dem gewünschten Automatisierungsgrad ab, in vielen Projekten ergänzen sich beide.

11. FAQ: Performance-Profiling mit Blackfire und XHProf