Time To First Byte optimieren

Generell gibt es verschiedene Möglichkeiten eine PHP-Anwendung in Bezug auf ihr Laufzeitverhalten zu analysieren. Jede bietet unterschiedliche Einblicke und Erkenntnisse. Allen ist gemein, dass die Messung Ressourcen benötigt und somit die Auslieferungszeit negativ beeinflusst — Rückschlüsse und Analysen beeinträchtigt das jedoch nicht. Besonders aussagekräftig, aber leider auch sehr
ressourcenintensiv, ist Xdebug. Deshalb wird es in Live-Umgebungen selten eingesetzt. Alternativ kann man messen, wann die Anwendung mit dem Betriebssystem kommuniziert. Diese System Calls bilden zwar nur einen Teil des Laufzeitverhaltens ab, sind allerdings minimalinvasiv: Sie sind ressourcenschonend, beeinflussen die Auslieferungszeit weniger und ermöglichen trotzdem sehr wertvolle Rückschlüsse auf die häufigsten Probleme.

Und darin verbirgt sich das Optimierungspotential, auf das wir nachfolgend eingehen.

Es ist notwendig, dass Dateien von der Festplatte angefragt und geladen werden. Schließlich ist hier festgehalten, welcher Programmcode ausgeführt werden soll. Werden jedoch sehr viele Dateien angefragt, oder beansprucht dieser Block einen wesentlichen Teil der Anfrage, ist dies häufig auf ein nicht ausreichendes Caching zurückzuführen. Es kann dir auch wertvolle Informationen über mögliche Optimierungen liefern.

Anhand der beteiligten Dateien lassen sich über den angezeigten Dateinamen Rückschlüsse darüber ziehen, welche Komponenten für die Seitenauslieferung herangezogen werden müssen. Stellst du fest, dass viel Zeit auf ungenutzte Plugins oder Themes verwendet wird, solltest du diese aus der Konfiguration deiner Applikation entfernen oder gezielt optimieren.

Diese Systematik kannst du auch auf andere Kategorien anwenden: Wird beispielsweise bei WordPress viel Zeit für die Datei wp-includes/widgets.php verwendet, solltest du deine eingesetzten Widgets genauer unter die Lupe nehmen.

Applikationsseitig stellen die verschiedenen Systeme (TYPO3, WordPress, etc.)
spezifische Möglichkeiten zum Caching bereit:

• TYPO3 wird von Haus aus mit Caching angeboten. Du kannst dies im Backend konfigurieren.
• Für WordPress stehen Plugins wie W3 Total Cache, WP Fastest Cache, WP
  Rocket oder WP Super Cache zur Verfügung.

Falls trotz aktivem Cache sehr viele Dateien eingelesen werden, kann das ein Hinweis auf ein Optimierungspotenzial in der Cache-Konfiguration sein. Ebenso ist es möglich, dass der OPCache nicht optimal eingerichtet ist. Der OPcache versucht häufig verwendete PHP-Dateien vorzuhalten, sodass diese nicht erst geöffnet und interpretiert werden müssen. Stellst du viele Aufrufe von PHP-Dateien fest, die zudem einen Großteil der Gesamtzeit ausmachen,
solltest du die Größe des OPcaches und seine Effektivität prüfen.

Dafür gibt es etliche Konfigurationsparameter für die php.ini, die wir uns jetzt genauer anschauen:

Dieser Wert gibt an, wie viel Arbeitsspeicher der OPCache maximal belegen soll. Wähle hier einen Wert mit ausreichend Puffer, damit möglichst alle PHP-Scripte im OPCache vorgehalten werden. Die aktuelle Auslastung kannst du mit Hilfe von opcache_get_status() auslesen. Alternativ gibt es auch grafische Oberflächen wie
opcache-gui, die genutzt werden können. Achte dabei immer darauf, dass nur du auf diese Daten zugreifen kannst, indem zum Beispiel ein Verzeichnisschutz davor geschaltet wird.

Steht dieser Parameter auf 1, wird beim Zugriff auf den OPCache geprüft, ob sich die angesprochenen Dateien verändert haben. Das ermöglicht es während der Entwicklung, nicht immer den OPCache leeren zu müssen. Gleichzeitig wird für diese Prüfung Zeit benötigt. Dadurch verlangsamt sich die Ausführung. Im Live-Betrieb kann man diese Validierung daher ausschalten.

Sofern opcache.validate_timestamps aktiv ist, wird mit diesem Parameter definiert, in welchen Intervallen (in Sekunden) die Validierung stattfinden soll. Der Default-Wert ist 2 Sekunden, wodurch in diesem Intervall einzelne Aufrufe etwas langsamer sein können.

Falls du auch noch das letzte Fünkchen Performance aus deiner Anwendung herausholen möchtest, lohnt sich ein Blick auf das Preloading. Damit können im OPCache Funktionen und Klassen etc. global verfügbar gemacht werden. Ohne Preloading erfolgt das Caching dateibasiert, was für die meisten Anwendungsfälle aber schon sehr schnell ist.

Die hier aufgeführten Konfigurationsparameter sind natürlich nicht das Ende der Fahnenstange. Für Einzelfälle kann daher ein Blick in die Doku nicht verkehrt sein.

Findest du in der Übersicht einzelne Dateien, die viel Zeit deiner TTFB in Anspruch nehmen, steht dies mit Programmausführungen in Verbindung. Zwar können wir an dieser Stelle nicht direkt in den Programmcode schauen. Du findest auf diesem Weg jedoch schneller den Verursacher.

Handelt es sich um PHP-Dateien, solltest du diese kritisch unter die Lupe nehmen und auf ineffiziente Programmierungen, blockierende Funktionsaufrufe oder unnötige Schleifen untersuchen. Handelt es sich um Assets wie Bilder, CSS-Dateien usw. werden diese in irgendeiner Form in deinem Programmcode verarbeitet. Zumindest bei einer gecachten Seite sollte das nur sehr selten passieren. Das liegt daran, dass Bilder und Co. direkt vom Webserver ausgeliefert werden. Die PHP-Prozesse sollten diese höchstens einmalig
verarbeiten, wenn beispielsweise ein Thumbnail generiert wird.

Generell gilt: Du kannst Dateioperationen nicht auf 0 reduzieren. Konzentriere dich lieber gezielt auf die obigen drei Bereiche, wenn eine langsame Seitenauslieferung vorliegt.

Für die meisten Webseiten sind zwei Verbindungen zu anderen Servern völlig normal: Einerseits zur Kommunikation mit der Datenbank und andererseits zur Kommunikation mit dem DNS-Server. Der Aufbau der Verbindung zu diesen sollte nie einen wesentlichen Anteil deiner TTFB darstellen.

Interessant wird es dann, wenn weitere Verbindungen auftauchen: Von all diesen ist die Auslieferungszeit deiner Seite abhängig. Ist ein Aufruf langsam, wirkt sich das direkt auf alle anderen Metriken deiner Webseite aus. Im Allgemeinen lässt sich sagen, dass die Kommunikation mit weiteren Servern auf Applikationsebene nur in seltenen Fällen überhaupt nötig ist. Identifiziere die Stellen und entferne die Verbindungen, wenn sie deine Seite negativ beeinträchtigen. Falls du Daten von externen Diensten auf deiner Webseite darstellen möchtest, sollten diese zum Beispiel separat im Frontend per Javascript nachgeladen werden. Die Datenverarbeitung kann dann in einem eigenen Prozess im Browser des Besuchers stattfinden, der nicht die initiale Generierungszeit auf dem Server beeinflusst.

Neben Caching sind nicht optimierte Queries die Hauptverdächtigen, wenn es um langsame Webseitenaufrufe geht. Aus diesem Grund findest du sie im mStudio explizit. Trügerisch dabei: In einem Produktivsystem mit einer gewachsenen Datenbank können sie über die Zeit deutlich langsamer werden und sich schlechter verhalten als in lokalen, puristischen Entwicklungsumgebungen. Wird die Datenbank größer, werden effektive Indizes wichtiger. Sticht eine Query in ihrer Ausführungszeit heraus, solltest du diese gezielt mit einem Index versehen und diesen im Deployment deiner Anwendung festhalten.

Herausfordernder zu optimieren sind hingegen sehr viele Queries, die einzeln vergleichsweise schnell, aber in ihrer Summe einen erheblichen Anteil der TTFB ausmachen oder identisch wiederholt ausgeführt werden. Dem zugrunde liegen häufig ineffiziente Programmschleifen, die jedes Mal die Datenbank anfragen. Optimiere solche Stellen gezielt dahingehend, dass die Datenbank weniger häufig angefragt wird.

In diesem Beitrag haben wir dir Probleme und Lösungswege vorgestellt, die häufig in Verbindung mit einer langsamen Seitenauslieferung stehen. Mit unserer Messung der Systemeaufrufe über das mStudio kommst du diesen Problemen auch in Produktivumgebungen schnell und mit wenig Messinterferenz auf die Schliche.