{"id":16681,"date":"2026-03-11T23:45:00","date_gmt":"2026-03-11T22:45:00","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=16681"},"modified":"2026-03-19T19:36:58","modified_gmt":"2026-03-19T18:36:58","slug":"php-beschleunigen-praxis","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/php-beschleunigen-praxis\/","title":{"rendered":"PHP mit OPcache, Variablen-Cache & JIT stark beschleunigen (Teil 2: Praxis)"},"content":{"rendered":"

Wie muss eine PHP-Installation aussehen, um von den zahlreichen Performance-Verbesserungen (v.a. Caching) der letzten Versionen zu profitieren? Dieser Beitrag demonstriert das an einer praktischen Umgebung, welche direkt f\u00fcr eigene Anwendungen oder dem Betreiben von Drittanbieter-Anwendungen genutzt werden kann. Darauf liegt der Fokus: Beispiele, die sich direkt ausprobieren sowie einsetzen lassen. Auf die Funktion & Hintergr\u00fcnde gehe ich an dieser Stelle nur nebenbei sowie rudiment\u00e4r ein. Wer dies vertiefen m\u00f6chte, findet mit dem ersten Teil einen kompletten Artikel, der die Details erl\u00e4utert<\/a>. Er ist als Grundlage empfehlenswert, um Aufbau & Entwicklung besser nachvollziehen zu k\u00f6nnen.<\/p>\n

Alle aktuellen Versionen profitieren stark<\/h2>\n

Zum Verfassungszeitpunkt dieses Artikels ist PHP 8.2 die \u00e4lteste Version, welche noch bis Ende 2026 mit Sicherheitskorrekturen versorgt wird. Alle unterst\u00fctzten Versionen k\u00f6nnen somit von den genannten Vorteilen profitieren. Allerdings ist nur der OPcache automatisch eingeschaltet, der Rest nicht. Und selbst das nur in bestimmten Konfigurationen. Ein offizielles Standard PHP 7.4 Docker Abbild beispielsweise l\u00e4sst den OPcache weiterhin vermissen:<\/p>\n

\n
\"\"<\/a><\/figure>\n<\/div>\n

Obwohl er bereits seit Version 5.5 zum Kern von PHP geh\u00f6rt. \u00c4hnliches kann auftreten, wenn von Distributionen angepasste Pakete zum Einsatz kommen. Eine Standard-Installation von PHP besteht bei mir daher im aktivieren aller Module sowie dem Installieren von APCu. Man sollte in der eigenen Umgebung stets zu Beginn pr\u00fcfen, welche Module installiert & aktiviert sind.<\/p>\n

Grunds\u00e4tzlich kann man sie in jeder Umgebung verwenden. Seit \u00fcber 10 Jahren laufen meine PHP-Installationen unter Docker. Es ist der flexibelste Weg. L\u00e4ngst existieren offizielle Abbilder, die das Installieren von Erweiterungen mit Hilfsfunktionen wie docker-php-ext-install <\/code>zum Kinderspiel machen. Daher zeige ich den folgenden Weg anhand der Dockerfiles meiner Projekte. Wer eine direkte Installation bevorzugt, kann die \u00c4nderungen auf manuellem Wege an die eigene Umgebung angepasst (z.B. Pfade von Konfigurationsdateien, Aufbau usw.) \u00fcbertragen.<\/p>\n

Nutzung in der Praxis: Aufbau – PHP + OPcache + JIT + APCu auf Docker<\/h2>\n

Als Basis verwende ich das von PHP offiziell bereitgestellte Apache-Abbild. Man kann hierbei bem\u00e4ngeln, dass mod_php f\u00fcr jede Anfrage einen PHP-Prozess startet. Ein Prozessmanager wie PHP-FPM ist effizienter, diesen setze ich bei den meisten meiner Projekte ein. Hier verzichte ich bewusst darauf, da er die Komplexit\u00e4t erh\u00f6ht. Der Fokus soll nicht auf dem Konfigurieren (und ggf. Verstehen) von PHP-FPM liegen. Sondern auf PHP mit Opcache, JIT & APCu. Zumal der Vorteil des Prozessmanagers in kleineren Umgebungen gering ist, doch das w\u00e4re Stoff f\u00fcr einen eigenen Beitrag. Auch auf weitere Komponenten wie PDO mit einem Datenbanktreiber (meist MySQL\/PostgreSQL) gehe ich an dieser Stelle nicht ein.<\/p>\n

Wir legen uns also ein Dockerfile an, in dem zun\u00e4chst APCu installiert werden muss. Dar\u00fcber hinaus ist nur das Aktivieren per Konfigurationsdatei notwendig. Die php.ini liegt im Apache-Abbild unter \/usr\/local\/etc\/php<\/code>.<\/p>\n

FROM php:8.5-apache\n# PHP >= 8.5 bundles OpCache, but only for caching bytecode of PHP scripts. APCu allows caching variables \nRUN pecl install APCu \\\n        && docker-php-ext-enable apcu<\/code><\/pre>\n
Das reicht f\u00fcr eine minimale Installation bereits aus. In php-overrides.ini<\/code> \u00fcberschreiben wir Einstellungen aus der standardm\u00e4\u00dfig vorhandenen php.ini<\/code>. <\/p>\n
opcache.enable=1\n; Speicher, der dem OPcache fuer bytecode zur Verfuegung steht\nopcache.memory_consumption=64MB\n; Speicherlimit fuer JIT\nopcache.jit_buffer_size=128M\nopcache.jit=tracing\n\n; "Aufwaerm" Skript, welches beim Start bereits geladen + gecached wird\n;opcache.preload=\/var\/www\/preload.php\n;opcache.preload_user=www-data\n\n; Limit fuer den Objektspeicher APCu\napc.shm_size=64M\n\n; Fehlersuche: 2 = Warnungen, 3 = Info, 4 = Debug\n;opcache.log_verbosity_level=4\n\n; Produktiv: revalidate_freq hoch setzen (Standard 2s) oder Pruefung ganz abschalten \n;opcache.validate_timestamps=0\n;opcache.revalidate_freq=0<\/code><\/pre>\n
Damit das funktioniert, lassen wir sie in docker-compose.yml<\/code> als letztes laden. Zur Vereinfachung bei Testzwecken erfolgt das Einh\u00e4ngen der PHP-Dateien als Volumes. Produktiv sauberer w\u00e4re es, diese per COPY<\/code> ins Docker-Abbild zu kopieren. Sowie \u00fcber develop.watch<\/code> auf \u00c4nderungen zu reagieren. Auch das entf\u00e4llt hier, um es simpel zu halten.<\/p>\n
services:\n  opcache-demo:\n    build: .\n    volumes:\n      - .\/www:\/var\/www\/html\n      - .\/preload.php:\/var\/www\/preload.php\n      - .\/php-overrides.ini:\/usr\/local\/etc\/php\/conf.d\/z-php-overrides.ini\n    ports:\n      - 80:80<\/code><\/pre>\n
Aufw\u00e4rmen mit Preload<\/em><\/h2>\n
Wir haben nun zwei robuste Zwischenspeicher. Allerdings mit einem Nachteil: Erst ab der zweiten Abfrage spielen sie ihre Karten aus. Der erste Besucher wird langsamere Ladezeiten abbekommen – insbesondere bei komplexen CMS bzw. Webanwendungen. Das kann durch Aufw\u00e4rmen<\/em> gel\u00f6st werden. Dabei laden wir wichtige Teile oder die komplette Applikation direkt nach dem Start in den Cache. Dies erledigt ein PHP-Skript, welches wir \u00fcber die opcache.preload<\/code> Direktive \u00fcbergeben. Dies kann theoretisch index.php sein, praktisch rate ich davon ab. In meinen Tests hat selbst die Ausgabe der PHP-Info zum Absturz des Webservers gef\u00fchrt.<\/p>\n
[Mon Feb 23 17:14:58.602586 2026] [:emerg] [pid 1:tid 1] AH00020: Configuration Failed, exiting<\/code><\/pre>\n
Stabiler funktioniert ein eigenes PHP-Skript, welches h\u00e4ufig ben\u00f6tigte Klassen\/Dateien l\u00e4dt. Ich platziere es au\u00dferhalb des \u00f6ffentlich zug\u00e4nglichen www<\/code> Ordners, also bei Apache in \/var\/www\/preload.php<\/code>. Darin m\u00fcssen keine Objekte Erzeugt werden – es gen\u00fcgt, die PHP-Skripte per require_once<\/code> zu laden.<\/p>\n
<?php\nrequire_once __DIR__ . '\/html\/demo.php';<\/code><\/pre>\n
Dass dies funktioniert, seht ihr mit opcache.log_verbosity_level=3<\/code> oder h\u00f6her. Er l\u00e4dt \u00fcber preload.php das Demo-Skript in den OPcache. Beim ersten Aufruf davon erscheint kein Logeintrag zum Caching mehr, weil es bereits drin liegt:<\/p>\n
opcache-demo-1  | Mon Feb 23 17:20:12 2026 (17): Message Cached script '$PRELOAD$'\nopcache-demo-1  | Mon Feb 23 17:20:12 2026 (17): Message Cached script '\/var\/www\/preload.php'\nopcache-demo-1  | Mon Feb 23 17:20:12 2026 (17): Message Cached script '\/var\/www\/html\/demo.php'\nopcache-demo-1  | 172.26.0.1 - - [23\/Feb\/2026:17:20:42 +0000] "GET \/demo.php HTTP\/1.1" 200 380 "-" "Mozilla\/5.0 (X11; Linux x86_64; rv:147.0) Gecko\/20100101 Firefox\/147.0"<\/code><\/pre>\n
Den Objekt-Cache benutzen<\/h2>\n
Im Gegensatz zum OPcache erfordert der Objekt-Cache Anpassungen am Code der Zielanwendung: Sie muss sinnvoll Daten in den Zwischenspeicher legen. Sowie im besten Falle diese leeren, sobald die gespeicherten Daten nicht mehr aktuell sind. Ein Simples Beispiel demonstriert folgendes Skript:<\/p>\n
<?php\n$date = new DateTime();\n$dt = $date->format('d.m.Y \\u\\m H:i:s');\n\n$added = (bool)apcu_add('datetime', $dt);\n$dtCached = apcu_fetch('datetime');\n?>\n<h2 style="font-family:Roboto">\n    Datum & Uhrzeit: <?=$dt?><br \/>\n    Zeitstempel vom Cache: <?=$dtCached?><br\/>\n    APCu gespeichert: <?=json_encode($added)?>\n<\/h2><\/code><\/pre>\n
Es gibt zuerst via $dt<\/code> den aktuellen Zeitstempel aus, welcher beim Aufruf des Skriptes neu generiert wird. Beim ersten Mal legt es ihn unter dem Schl\u00fcssel datetime<\/code> in APCu ab. Wer die Doku aufmerksam lie\u00dft, stellt fest: apcu_add<\/code> speichert nur, sofern noch nichts im Zwischenspeicher liegt. Dagegen w\u00fcrde apcu_store<\/code> s\u00e4mtliche vorhandenen Daten immer \u00fcberschreiben. Der erste Aufruf schreibt den Zeitstempel in den Cache. Die sp\u00e4teren Anfragen zeigen zwei verschiedene Zeitstempel an: Der Erste ist live generiert, weil normale PHP-Variablen w\u00e4hrend #2 dem ersten Laden entspricht.<\/p>\n
W\u00e4hrend das eine gute Demonstration zum Verst\u00e4ndnis der Funktion f\u00fcr den ersten Einstieg darstellt, ist es im praktischen Einsatz sinnlos. Dort w\u00fcrde man wie folgt vorgehen: Pr\u00fcfen, ob der Schl\u00fcssel bereits im Cache liegt – wenn ja, ihn von dort laden. Andernfalls m\u00fcssen die Daten geladen\/generiert\/aufbereitet werden. Zus\u00e4tzlich speichern wir sie f\u00fcr den sp\u00e4teren Abruf im Cache. Der Zeitstempel steht hier beispielhaft f\u00fcr umfangreichere Daten, etwa von einer Datenbankabfrage, einem API-Aufruf oder andere komplexere Quellen.<\/p>\n
<?php\n$key = 'datetime';\nif(apcu_exists($key)) {\n    $dt = apcu_fetch($key);\n}else {\n    $date = new DateTime();\n    $dt = $date->format('d.m.Y \\u\\m H:i:s');\n    apcu_add($key, $dt);\n}\n?>\n<h2 style="font-family:Roboto">\n    Zeitstempel vom Cache: <?=$dt?>\n<\/h2><\/code><\/pre>\n
Produktiv w\u00e4re es am besten, wenn die Anwendung den Zwischenspeicher automatisch leert, um immer aktuelle Daten auszuliefern. Ein Beispiel: Wir speichern die Liste der neuesten Blogbeitr\u00e4ge in APCu. Beim Hinzuf\u00fcgen neuer Eintr\u00e4ge ruft die Anwendung apcu_delete()<\/code> auf. So erscheinen keine \u00e4lteren Eintr\u00e4ge. Ist das nicht m\u00f6glich, weil die Daten von au\u00dfen ver\u00e4ndert werden, kann alternativ zumindest eine TTL (Time-to-live) angegeben werden. Daf\u00fcr akzeptiert apcu_add<\/code> als dritten Parameter die Anzahl an Sekunden. Folgendes Beispiel speichert das Datum im Schl\u00fcssel „key“ f\u00fcr maximal 10 Minuten.<\/p>\n
apcu_add('date', '23.02.2026', 60*10);<\/code><\/pre>\n
Statistiken: Wie geht es den Caches?<\/h2>\n
Alle Komponenten stellen PHP-Funktionen bereit, um den Status auslesen zu k\u00f6nnen. Ich habe mir dazu eine kleine Fu\u00dfzeile gebaut, welche die interessantesten Metriken darstellt. Zu Beginn von index.php (mein MVC-Router) wird die Zeit festgehalten:<\/p>\n
define('SCRIPT_START_TIME', microtime(true));<\/code><\/pre>\n
So l\u00e4sst sich am Ende die Generierungszeit berechnen. Dies stelle ich zusammen mit weiteren Messwerten (etwa dem RAM-Verbrauch) sowie den Statistiken der Caches in einer kleinen unauff\u00e4lligen Box dar. Wichtig ist, dass folgender Code am Ende des Skripts aufgerufen wird! Erfolgt der Aufruf fr\u00fcher, sind Werte wie die Ausf\u00fchrungszeit oder der RAM-Verbrauch nicht korrekt. Auch die Cache-Statistik kann fehlerhaft sein, falls danach weitere Zugriffe stattfinden. Interessant ist es, nach einiger Zeit produktiver Nutzung auf die Zahlen zu Blicken. So l\u00e4sst sich erkennen, ob die reservierten Dimensionen ausreichen, oder angepasst werden k\u00f6nnen\/sollten.<\/p>\n
<?php\n$totalExecutionTime = round((microtime(true) - SCRIPT_START_TIME) * 1000, 1);\n$filesCount = count(get_included_files());\n$memory = round(memory_get_peak_usage(real_usage: false) \/ 1000, 1);\n$realMemory = round(memory_get_peak_usage(real_usage: true) \/ 1000, 1);\n$peakMemory = round(memory_get_peak_usage(real_usage: false) \/ 1000, 1);\n$realPeakMemory = round(memory_get_peak_usage(real_usage: true) \/ 1000, 1);\n\n$opcache = opcache_get_status();\n\n$apcuCache = apcu_sma_info();\n$apcuSize = round($apcuCache['seg_size'] \/ 1000 \/ 1000, 1);\n$apcuAvailable = round($apcuCache['avail_mem'] \/ 1000 \/ 1000, 1);\n\n$apcuInfo = apcu_cache_info();\n?>\n<style>\n  #stats-box {\n    color: #A9A9A9; \n    text-align: center; \n    margin-top: -10px; \n    padding-bottom: 10px; \n    font-size: 12px;\n    font-family: Roboto,Verdana;\n  }\n<\/style>\n<div id="stats-box">\n  Generiert in <?=$totalExecutionTime?>ms mit <?=$filesCount?> Dateien, <?=$memory?> KB Arbeitsspeicher (Real: <?=$realMemory?> KB), Spitze: <?=$peakMemory?> KB (Real: <?=$realPeakMemory?> KB)<br \/>\n  OPCache: <?=$opcache['opcache_statistics']['num_cached_scripts']?> Skripte, <?=$opcache['opcache_statistics']['hits']?> Hits, <?=$opcache['opcache_statistics']['misses']?> Misses, Hit-Rate: <?=round($opcache['opcache_statistics']['opcache_hit_rate'], 1)?>% <br \/>\n  APU: <?=$apcuAvailable?> MB von <?=$apcuSize?> MB verf\u00fcgbar | <?=$apcuInfo['num_entries']?>\/<?=$apcuInfo['num_slots']?> Slots verwendet | <?=$apcuInfo['num_hits']?> Hits, <?=$apcuInfo['num_misses']?> Misses<\/code><\/pre>\n
Hinweis<\/strong>: Jeder apcu_exists()<\/code> Aufruf wird als Cache-Hit gewertet! Daher generiert obiges Skript pro Ladevorgang zwei Hits. <\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
\u00dcbersicht & Analyse per Skript<\/h2>\n
Mit dem php-cache-dashboard existiert ein simples Skript, welches zur \u00dcbersicht \u00fcber den gesamten Cache ideal ist.1<\/a><\/sup> Es besteht aus einer einzigen PHP-Datei (cache.php), sodass es ohne gro\u00dfartige Installation leicht abgelegt & sp\u00e4ter wieder entfernt werden kann. Angezeigt wird Opcache, APC (PHP < 5.5)\/APCu (ab 5.5) und sogar der Realpath-Zwischenspeicher. Auch Redis als externe, verteilte L\u00f6sung wird abgefragt. Die Auslastung ist grafisch dargestellt. Auf Wunsch zeigt das Skript die zwischengespeicherten Dateien als Tabelle mit Meta-Infos (Hits, Gr\u00f6\u00dfe). Au\u00dferdem lassen sich die derzeit abgelegten Schl\u00fcssel mit ihren Werten anzeigen sowie durchsuchen. F\u00fcr Tests k\u00f6nnen einzelne Schl\u00fcssel oder der ganze Cache geleert werden. Damit eignet es sich besonders gut f\u00fcr Anwendungen, in denen man eine \u00dcbersicht nicht selbst integrieren kann oder m\u00f6chte – etwa ein CMS.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Achtung<\/strong>: Da php-cache-dashboard auch das L\u00f6schen des Zwischenspeichers erm\u00f6glicht, sollte man es m\u00f6glichst nicht (dauerhaft) ungesch\u00fctzt \u00f6ffentlich erreichbar zug\u00e4nglich machen.<\/p>\n
Unabh\u00e4ngig von der Datenquelle sollte man nach einiger Zeit der produktiven Nutzung die Auslastung des Cache pr\u00fcfen. Je nach Anwendung l\u00e4sst sich der reservierte Speicher deutlich verkleinern. Oder er ist zu knapp bemessen, wodurch nur ein Teil seines Potenzials nutzbar ist.<\/p>\n
Weitere Einstellungen<\/h2>\n
Ein Blick in die Dokumentation lohnt sich. Dort sind alle OPcache Direktiven mit ihren Standardwerten dokumentiert. Klickt man darauf, folgt weiter unten eine Erkl\u00e4rung.2<\/a><\/sup> Selbiges gilt f\u00fcr APCu.3<\/a><\/sup> Dort finden sich zudem Hilfsfunktionen wie apcu_inc\/apcu_dec<\/code>: Sie k\u00f6nnen Werte zu Variablen hinzu z\u00e4hlen. Das vereinfacht den Umgang mit Z\u00e4hlern, weil man sich die obige Logik Laden wenn vorhanden\/andernfalls abspeichern<\/em> spart.<\/p>\n
Folgende Direktiven k\u00f6nnen f\u00fcr manche interessant sein:<\/p>\n