{"id":16470,"date":"2026-03-01T23:39:00","date_gmt":"2026-03-01T22:39:00","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=16470"},"modified":"2026-04-02T17:24:54","modified_gmt":"2026-04-02T16:24:54","slug":"php-caches-performance-funktion","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/php-caches-performance-funktion\/","title":{"rendered":"PHP schneller & effizienter machen: So funktionieren OPcache, Variablen-Cache, JIT & co."},"content":{"rendered":"

Die Leistung von PHP-Anwendungen l\u00e4sst sich deutlich verbessern. Das reduziert Ladezeiten & Serverlast. W\u00e4hrend der OPcache jedes PHP-Projekt ohne Anpassungen beschleunigt, wird der Zwischenspeicher f\u00fcr Variablen in den Code integriert. Dieser Artikel stellt beide Varianten sowie den neuen JIT-Compiler vor und fasst ihre Umbr\u00fcche aus der historische Entwicklung zusammen. Er soll als Einstieg dienen, um Verst\u00e4ndnis f\u00fcr die Funktionsweise von PHP aufzubauen. Sowie \u00fcber die daraus entstehenden Probleme in der Leistungsf\u00e4higkeit. So lassen sich die gefundenen L\u00f6sungen verstehen. Im zweiten Teil werden wir s\u00e4mtliche Optimierungen in der Praxis am Demo-Beispiel eines Apache-Webservers mit PHP-Modul anwenden.<\/p>\n

Die Sprache des WWW<\/h2>\n

Seit Jahren wird PHP f\u00fcr tot erkl\u00e4rt, weil angeblich moderne<\/em> Sprachen wie JavaScript (im gleichen Jahr entstanden) sie abl\u00f6sen. Ebenso lange ist das nicht eingetroffen, im Gegenteil. Zum Stand M\u00e4rz 2026 wird PHP laut W3Techs-Erhebung auf satten 72% der Webseiten eingesetzt – und liegt damit bis heute mit gro\u00dfem Abstand auf Platz 1.1<\/a><\/sup> Alle danach erreichen nur einstellige Marktanteile. Selbst das vielbeschworene JS erzielt lediglich eine Verbreitung von 5,7%. <\/p>\n

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

Nicht nur deswegen lohnt sich eine ausf\u00fchrlichere Auseinandersetzung mit PHP: Die Skriptsprache wies zwar f\u00fcrchterliche Eigenheiten auf. Doch das hat sich seit Jahren kontinuierlich verbessert. Ab PHP 7 ist ein deutlicher Schub erkennbar. Die Verbesserungen der Sprache selbst w\u00fcrden den Rahmen sprengen und sind einen eigenen Beitrag wert. Hier soll der Fokus auf der Leistung liegen. Ein Kritikpunkt an PHP war die mangelnde Effizient. Er hatte seine Berechtigung – doch mittlerweile wurden sogar zahlreiche zuvor extern existierende Werkzeuge in den Kern der Sprache integriert, die vieles deutlich besser machen. <\/p>\n

Bevor du erf\u00e4hrst, was sich konkret verbessert hat, erkl\u00e4re ich die Gr\u00fcnde sowie Funktionsweise. Im sp\u00e4teren Verlauf wird auf die Konfiguration eingegangen. Schlussendlich legen wir uns eine simple Demo-Umgebung an, welche von Zwischenspeichern & weiteren Optimierungen profitieren.<\/p>\n

So funktioniert PHP<\/h2>\n

Beide Arten funktionieren komplett unterschiedlich. Um das nachvollziehen zu k\u00f6nnen, ist ein grundlegendes Verst\u00e4ndnis davon notwendig, wie ein Webserver PHP-Anfragen abarbeitet. Das funktioniert im Wesentlichen in vier Schritten. Gehen wir von einem bekannten Apache2 mit mod_php<\/code> aus. In klassischen Webservern sind Skriptsprachen wie PHP nicht integriert, sodass diese \u00fcber ein Modul an den PHP-Interpreter weitergeleitet werden.<\/p>\n

    \n
  1. Der Browser sendet durch das Aufrufen einer Seite eine HTTP-Anfrage (GET \/demo.php)<\/li>\n
  2. Der Webserver startet den PHP-Interpreter & f\u00fchrt das Skript aus<\/li>\n
  3. PHP erzeugt HTML als Ausgabe<\/li>\n
  4. Diese Ausgabe wird vom Webserver als Antwort (HTTP Body) an den Browser gesendet<\/li>\n<\/ol>\n

    Optimierungspotenzial besteht in Schritt 2: PHP ist eine Interpreter-Sprache. Der Code wird bei jedem Aufruf neu vom Interpreter ausgef\u00fchrt. Damit unterscheidet es sich von kompilierten Sprachen wie etwa C++ oder C: Sie werden vom Compiler einmalig in Maschinencode \u00fcbersetzt. Es entsteht eine ausf\u00fchrbare Datei, die mit hoher Leistung nutzbar ist. Interpreter-Sprachen sind flexibler, doch auch langsamer & ben\u00f6tigen mehr Leistung – schlie\u00dflich muss der Interpreter bei jeder HTTP-Anfrage den PHP-Code von der Festplatte lesen und ausf\u00fchren.<\/p>\n

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

    OPcache macht den PHP-Interpreter effizienter<\/h2>\n

    F\u00fcr Webseiten oder Webanwendungen ist das wenig sinnvoll. Schlie\u00dflich \u00e4ndern sich PHP-Dateien nur selten – folglich f\u00fchrt der Interpreter dutzendfach den selben Code aus. Um das zu reduzieren, erzeugt OPcache mit Bytecode eine Zwischenschicht von PHP & dem Maschinencode. Er kann von einer VM (ab PHP 5.5 Zend) gelesen werden, wodurch der Rechenaufwand deutlich sinkt. Sie ist eine einheitliche Laufzeitumgebung und abstrahiert verschiedene Betriebssysteme sowie CPU-Architekturen. Da der Bytecode im Arbeitsspeicher liegt, entfallen zudem I\/O Zugriffe. Schlie\u00dflich teilt sich Code oft auf zig PHP-Dateien auf, die zuvor vom Laufwerk geladen werden m\u00fcssen – ebenfalls bei jeder HTTP-Anfrage. <\/p>\n

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

    Ein OPcache lie\u00dft PHP-Skripte einmalig aus dem Dateisystem & speichert sie als Bytecode in den RAM. Insbesondere bei komplexeren Anwendungen, die aus vielen Codezeilen sowie Dateien bestehen, kann es die Geschwindigkeit deutlich verbessern. Parallel sinkt die Serverlast. Wie stark dies ausf\u00e4llt, h\u00e4ngt vom konkreten Szenario ab. Da es sich hierbei um die interne Verarbeitung handelt, ist keine OPcache-Unterst\u00fctzung der Anwendung erforderlich.<\/p>\n

    Wozu ein Variablen-Cache (bzw. User-Cache)?<\/h2>\n

    Das HTTP-Protokoll ist zustandslos – bedeutet konkret: Jede Anfrage ist in sich geschlossen. Es werden keine Informationen aus Anfrage A in Anfrage B zur Verf\u00fcgung gestellt. Die einzige Ausnahme sind Cookies, welche vom Browser in zuk\u00fcnftigen Anfragen mitgesendet werden. Auch PHP ist standardm\u00e4\u00dfig Zustandslos: S\u00e4mtliche Variablen und sonstige Objekte entsorgt der Garbage Collector, nachdem die Anfrage abgeschlossen wurde.<\/p>\n

    Wie man sich denken kann, ist das nicht ideal. Schlie\u00dflich sind viele Elemente einer Seite f\u00fcr alle oder einen Gro\u00dfteil der Besucher identisch. Ein konkretes Beispiel w\u00e4ren die Widget-Boxen rechts f\u00fcr die neuesten Inhalte. Es ist unn\u00f6tig, diese tausende male am Tag f\u00fcr jede Anfrage mit den gleichen Inhalten neu zu laden. Besonders kritisch wird es f\u00fcr die Performance, wenn diese eine aufw\u00e4ndige SQL-Abfrage erfordern. Oder sie ein API-Aufruf von einer externen Seite l\u00e4dt. Neben der Geschwindigkeit kommen dort au\u00dferdem Blockaden hinzu, falls die Zahl der Anfragen \u00fcberhand nimmt.<\/p>\n

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

    Die L\u00f6sung liegt auf der Hand: Ein Speicher, der Variablen \u00fcber verschiedene Anfragen hinweg im RAM ablegt. Das ist der Variablen-Cache bzw. User-Cache. \u00dcber bestimmte PHP-Funktionen lassen sich Variablen in Anfrage A setzen, um sie in B & C abzurufen.<\/p>\n

    Prozessmanager wie PHP-FPM beschleunigen an anderer Stelle<\/h2>\n

    An dieser Stelle sei auf ein weiteres gel\u00f6stes Problem hingewiesen: Am einfachsten l\u00e4sst sich PHP mit Apache2 und dem PHP-Modul (mod_php<\/em>) nutzen. Man muss lediglich das Modul installieren & aktivieren. Intern funktioniert es sehr simpel, in dem f\u00fcr jede HTTP-Verbindung ein PHP-Prozess gestartet wird (mpm_prefork<\/em> Modus). Es werden also st\u00e4ndig neue, kurzlebige Prozesse gestartet. Je mehr Verbindungen, um so h\u00f6her sind RAM-Verbrauch & CPU-Nutzung durch diese vielen Prozesse – das ist der erste Nachteil.<\/p>\n

    $ apachectl -V | grep MPM\nServer MPM:     prefork<\/code><\/pre>\n
    Durch die tiefe Integration in Apache h\u00e4ngt alles miteinander zusammen & verursacht unn\u00f6tige Mehrlast: Jeder Apache-Prozess enth\u00e4lt den PHP-Interpreter sowie s\u00e4mtliche Apache-Module. Eine statische Anfrage beinhaltet Bestandteile von PHP, w\u00e4hrend PHP-Anfragen umgekehrt (irrelevante) Module des Webservers mit sich schleppen. Das ist ineffizient, aber nicht zwingend ein Problem. F\u00fcr weniger frequentiere Seiten kann es ausreichen.<\/p>\n
    Besser geht es durch die Trennung von Webserver & PHP: Prozessmanager wie PHP-FPM starten einen Pool aus PHP-Prozessen, die sich ausschlie\u00dflich darum k\u00fcmmern. Der Webserver leitet nur PHP-Anfragen dort hin weiter. Apache bietet npm_worker_mdoule<\/em>, welches mehrere Threads pro Prozess startet. Allerdings ist PHP nicht threadsicher. PHP-FPM skaliert besser. Dies wird nur am Rande erw\u00e4hnt, weil nichts mit dem Caching zu tun hat. Sondern mit dem grunds\u00e4tzlichen Stack, davon sind die folgenden Optimierungen unabh\u00e4ngig: Sie k\u00f6nnen sowohl mit mod_php, als auch PHP-FPM verwendet werden.<\/p>\n
    Ein Schwenk in die Geschichte der PHP-Beschleuniger: Warum es ist, wie es ist<\/h2>\n
    Bislang habe ich nur die allgemeine Funktionsweise beschrieben. Da PHP dieses Thema lange vernachl\u00e4ssigte, schuf die Gemeinschaft verschiedene Quelloffene L\u00f6sungen. Einer der \u00e4ltesten ist APC: Der Alternative PHP Cache<\/em> entstand in den fr\u00fchen 2000er Jahren, bis er 2012 eingestellt wurde. XCache schuf 2006 ein Lighttpd-Entwickler – ihn habe ich damals erstmals auf U-Labs eingesetzt. Beide bieten sowohl OPCache, als auch das Zwischenspeichern von Variablen. Dagegen konnte eAccelerator nur den PHP-Code im interpretierten Zustand speichern.<\/p>\n
    Viele Projekte sahen sich als obsolet, als PHP mit Version 5.5 begann, die Zend OPcache Erweiterung auszuliefern.2<\/a><\/sup> Urspr\u00fcnglich war APU im Gespr\u00e4ch, doch das PHP-Team entschied sich f\u00fcr Zend. Bewusst soll sie nur Bytecode zwischenspeichern, keine Objekte aus dem Nutzercode. Modularit\u00e4t, Stabilit\u00e4t & geringe Komplexit\u00e4t wurden priorisiert. Dadurch fehlte weiterhin ein Objekt-Cache.<\/p>\n
    Diese L\u00fccke wollte APC f\u00fcllen und erlangte als APCu die Wiedergeburt.<\/em> APC selbst musste eingestellt werden: Da es OPcache & Variablen-Cache enth\u00e4lt, war es nicht mehr mit PHP ab 5.5 kompatibel. Zumindest wenn Zend OPcache aktiviert wurde, kam es zum Konflikt. Zur L\u00f6sung entfernte APCu den OPcache. Somit r\u00fcstet man den fehlenden Zwischenspeicher f\u00fcr Variablen mittels APCu nach.<\/p>\n
    Weiterentwicklung des Zend OPcache<\/h2>\n
    PHP 5.5 erschien initial im Jahr 2013. In den ~13 Jahren wurde der OPcache \u00fcber verschiedene PHP-Versionen hinweg verbessert: In Version 7.0 wurde die Zend Engine in Version 3 komplett \u00fcberarbeitet. Man kann den Cache zus\u00e4tzlich im Dateisystem ablegen. Das beschleunigt die Neuverwendung nach dem Neustart, wodurch dieser bislang komplett neu aufgebaut werden musste. Oder falls der RAM-Cache ausgelastet ist. Generell brachte PHP 7.0 einige Performance-Verbesserungen gegen\u00fcber 5.x, man kann per Faustformel von etwa 50% ausgehen. Technisch wurde au\u00dferdem das Konzept des AST (Abstract Syntax Tree<\/em>) eingef\u00fchrt, welches Parser & Compiler aufteilt.<\/p>\n
    Den ersten Start verbessert PHP 7.4 mit Preloading. In der php.ini<\/code> Direktive opcache.preload<\/code> kann der Pfad zu einer PHP-Datei angegeben werden, welche direkt beim Start geladen & in den OPcache abgelegt werden soll. Zuvor bekam der erste Nutzer ein tendenziell schlechteres Erlebnis, vor allem beim Einsatz umfangreicher Frameworks.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Der JIT erweitert den OPcache<\/h2>\n
    Ab PHP 8.0 kann JIT (Just-In-Time Compilation<\/em>) zusammen mit OPcache sogar Maschinencode erzeugen.3<\/a><\/sup> Bestimmte Codebereiche werden zur Laufzeit in Maschinencode statt Bytecode \u00fcbersetzt. Es existieren zwei Arten: „Function JIT“ kompiliert Funktionen beim ersten Aufruf. Er ist stabiler, daf\u00fcr f\u00e4llt der Performance-Gewinn geringer aus. „Tracing JIT“ dagegen analysiert, welche Codepfade zur Laufzeit h\u00e4ufig ausgef\u00fchrt werden & kompiliert nur diese – das kann effizienter sein, in synthetischen Benchmarks 1,5x bis 2x besser. Die OPcache Erweiterung ist seit dem nicht mehr optional, d.H. PHP l\u00e4sst sich nur noch zusammen mit ihr kompilieren.<\/p>\n
    Dieser Weg wurde in PHP 8.1 beibehalten: Verbesserungen am JIT machen die Technik stabiler. Auch der OPcache profitiert von Optimierungen.4<\/a><\/sup> Wie stark, variiert je nach Anwendung. Bei einer Symfony-Demo ist 8.1 um 23% schneller, WordPress beschleunigt sich um 3,5%. Au\u00dferdem ist der JIT nun auch f\u00fcr ARM64 und damit langfristig auf Einplatinencomputern wie dem Raspberry Pi verf\u00fcgbar.<\/p>\n
    Umfangreiche Nutzung: Beispiel WordPress<\/h2>\n
    Der Effekt variiert abh\u00e4ngig von der Anwendung. Wer bereits bei der Entwicklung auf Effizient geachtet hat, wird mit Caching weniger heraus holen k\u00f6nnen. \u00c4hnlich wie beim Komprimieren von Dateien: Selbst vergleichsweise ineffiziente Algorithmen wie Zip k\u00f6nnen Text stark verkleinern. Bei bereits komprimierten Formaten wie JPG dagegen ist die Ersparnis sehr gering.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Bei CMS ist sie meist hoch, weil Funktionsumfang & Flexibilit\u00e4t h\u00e4ufig als wichtiger bewertet werden, als ein kleiner Fu\u00dfabdruck. Das verbreitetste ist WordPress. Eine produktive Installation die Plugins bewusst sparsam einsetzt, hat \u00fcber 730 PHP-Skripte im Zwischenspeicher liegen. Dort kann es einiges bewirken. Bereits wegen der umfangreichen Aufteilung auf viele verschiedene PHP-Dateien.<\/p>\n
    APCu oder Hype-Anwendungen<\/em> wie Redis\/Valkey\/Memcached?<\/h2>\n
    Das Konzept von Schl\u00fcssel-Wert-Speichern im Arbeitsspeicher ist keineswegs neu, sondern ebenfalls gewachsen. Viele werden Redis als bekanntesten Vertreter kennen, gegr\u00fcndet bereits 2009. Valkey ist eine 2024 von der Open Source Initiative geschaffene Abspaltung als Reaktion auf Redis Wechsel von BSD zu einem dualen Lizenzmodell. Memcached ist noch \u00e4lter und erschien erstmals 2003. <\/p>\n
    Die grunds\u00e4tzliche Funktion aller drei ist identisch, es gibt jedoch einen entscheidenden Unterschied: Redis, Valkey & Memcached sind verteilte Caches. Man verbindet sich per TCP, wie zu einem Datenbankserver. So wird Skalierung erm\u00f6glicht, weil sich der Schl\u00fcssel-Wert-Cache auf einem eigenen Server befinden kann – oder gar einem ganzen Cluster. F\u00fcr sehr gro\u00dfe Seiten lohnt sich das – trotz der h\u00f6heren Latenz, die durch TCP-Verbindungen entsteht. Kleine bis mittelgro\u00dfe Webanwendungen profitieren mehr von APCu. Dort liegt alles auf dem gleichen Server, mehr Leistung\/Speicher ist ausschlie\u00dflich durch Aufr\u00fcsten m\u00f6glich.5<\/a><\/sup><\/p>\n
    Oft wird Skalierung \u00fcbersch\u00e4tzt. Man ben\u00f6tigt sehr viele Besucher (oder sehr ineffizienten Code), um einen halbwegs solide ausgestatteten Server an seine Grenzen zu bringen. Wer dennoch diese Ambitionen hat, baut sich eine Caching-Klasse zur Abstrahierung. Das hat mir bereits anderweitig geholfen: Beim Wechsel des mittlerweile eingestellten Xcache zu APCu.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Diese versteckten Bremsen geh\u00f6ren nicht zu PHP<\/h2>\n
    Der klassische Ansatz ohne jegliche Zwischenspeicher war keine Sternstunde hoher Performance. Das ist offensichtlich – schlie\u00dflich musste jede Anfrage zig PHP-Dateien laden und vom Interpreter ausf\u00fchren lassen. W\u00e4hrend dies seit langem gel\u00f6st ist, freut sich ein anderer Bremsklotz gro\u00dfer Beliebtheit: Frameworks.<\/p>\n
    H\u00e4ufig werden sie nur zu einem Bruchteil ausgereizt und vergr\u00f6\u00dfern die Angriffsfl\u00e4che sowie den Wartungsaufwand. Caching kann ersteres nur abschw\u00e4chen, gegen den Rest ist es machtlos. Ich verzichte daher in aller Regel auf riesige Frameworks wie Symfony & co. F\u00fcr sinnvolle Konstrukte wie z.B. MVC habe ich eigene minimalistische L\u00f6sungen entwickelt. Sie sind bereits ohne Caching pfeilschnell und gehen dabei sparsam mit Ressourcen um.<\/p>\n
    Damit m\u00f6chte ich Frameworks nicht pauschal f\u00fcr jeden Anwendungsfall verteufeln. Sie k\u00f6nnen n\u00fctzlich sein – doch nur, wenn sie im Verh\u00e4ltnis zu den Anforderungen stehen. Hier scheitert es oft, etwa weil man sich mit Framework X auskennt. Daher kommt es zum Einsatz, obwohl eine schlankere L\u00f6sung ausreichen w\u00fcrde. Ebenfalls verbreitet ist Overengineering: Der Entwickler ist sich im klaren dar\u00fcber, ein viel zu umfangreiches Framework einzusetzen. Doch er rechnet damit, dass vielleicht sp\u00e4ter noch mehr dazu kommt, womit es sich rechnet. Weitsicht ist vern\u00fcnftig, doch sie muss Grenzen kennen. Oft kommt es nicht so weit. Daf\u00fcr hat man bis dahin eine ineffiziente Anwendung mit hohem Wartungsaufwand. Schlie\u00dflich erfordert das Framework regelm\u00e4\u00dfige Pflege & Anpassungen am Code.<\/p>\n
    Fazit<\/h2>\n
    Es hat relativ lange gedauert, bis das PHP-Team mit Version 5.5 die Sinnhaftigkeit eines OPcache im Kern erkannt hat. Daf\u00fcr wurde es im Laufe der Versionen mit neuer Engine (PHP 7.0), dem Aufw\u00e4rmen (PHP 7.4) und ab PHP 8.0 dem JIT stetig verbessert. Ein Zwischenspeicher f\u00fcr Variablen fehlt zwar. Doch diese L\u00fccke f\u00fcllt APCu problemlos. Dies ist ein Gebiet, auf dem die Skriptsprache in den letzten Jahren deutlich aufgewertet wurde. Der Performance-Abstand zu dauerhaft laufenden Anwendungsservern (Gogs, NodeJS, .NET usw) schwindet weiter. Heute ist es leichter denn je, performante PHP-Webanwendungen zu entwickeln.<\/p>\n
    Nicht \u00fcbersehen werden sollte: Der gr\u00f6\u00dfte Killer sind umfangreiche Frameworks. Man kann sie mit OPcache & co. zwar weniger schlimm machen – doch niemals so performant, wie eine passende L\u00f6sung. Ganz zu schweigen vom h\u00f6heren Aufwand und der gesteigerten Angriffsfl\u00e4che. Statt zu versuchen, unn\u00f6tig umfangreiche Frameworks auf dieser Ebene weniger langsam zu machen, sollte man daher lieber von Anfang an pr\u00fcfen & hinterfragen: Was brauche ich wirklich? Ist ein Framework daf\u00fcr tats\u00e4chlich notwendig, wenn ja welches? <\/p>\n
    Quellen<\/h2>\n
      \n
    1. https:\/\/w3techs.com\/technologies\/overview\/programming_language<\/a> \u21a9\ufe0e<\/a><\/li>\n
    2. https:\/\/www.php.net\/releases\/5_5_0.php<\/a> \u21a9\ufe0e<\/a><\/li>\n
    3. https:\/\/www.php.net\/releases\/8.0\/en.php<\/a> \u21a9\ufe0e<\/a><\/li>\n
    4. https:\/\/www.php.net\/releases\/8.1\/en.php<\/a> \u21a9\ufe0e<\/a><\/li>\n
    5. https:\/\/reintech.io\/blog\/guide-php-apcu-library-caching-performance-optimization<\/a> \u21a9\ufe0e<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
      Die Leistung von PHP-Anwendungen l\u00e4sst sich deutlich verbessern. Das reduziert Ladezeiten & Serverlast. W\u00e4hrend der OPcache jedes PHP-Projekt ohne Anpassungen beschleunigt, wird der Zwischenspeicher f\u00fcr Variablen in den Code integriert. Dieser Artikel stellt beide Varianten sowie den neuen JIT-Compiler vor und fasst ihre Umbr\u00fcche aus der historische Entwicklung zusammen. Er soll als Einstieg dienen, um …<\/p>\n","protected":false},"author":5,"featured_media":16680,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"https:\/\/w3techs.com\/technologies\/overview\/programming_language<\/a>\",\"id\":\"7252e6b3-b0f4-4b1c-b1ac-88dd88e8730b\"},{\"content\":\"https:\/\/www.php.net\/releases\/5_5_0.php<\/a>\",\"id\":\"28b97496-3f66-4f0d-b31a-63465ee5a74b\"},{\"content\":\"https:\/\/www.php.net\/releases\/8.0\/en.php<\/a>\",\"id\":\"3fa07781-8dd1-4c1d-bb81-e2a1273c6103\"},{\"content\":\"https:\/\/www.php.net\/releases\/8.1\/en.php<\/a>\",\"id\":\"7c3fe19a-6a87-4cd4-8adb-fb2ff2075aea\"},{\"content\":\"https:\/\/reintech.io\/blog\/guide-php-apcu-library-caching-performance-optimization<\/a>\",\"id\":\"05d2a048-e098-4f54-85da-01d8e85aaa90\"}]"},"categories":[61],"tags":[55],"class_list":["post-16470","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-softwareentwicklung","tag-php"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=16470"}],"version-history":[{"count":100,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16470\/revisions"}],"predecessor-version":[{"id":17184,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16470\/revisions\/17184"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/16680"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=16470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=16470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=16470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}