Archive for the ‘APC’ tag
APCu: Der neue User-Cache
Speziell für PHP 5.5 gibt es die User-Cache-Extension APCu: Seit PHP 5.5 ist der Bytecode-Cache OpCache enthalten, die bisher genutzte Extension APC wird dann nicht mehr benötigt. Doch wer APC nicht nur wegen seiner Bytecode-Cache-Fähigkeit installiert sondern auch die User-Cache-Funktionen genutzt hat, kann jetzt die abgespeckte Erweiterung APCu nutzen, in der alle Bytecode-Funktionen entfernt wurden.
(Wer die Upload-Progress-Funktionen von APC genutzt hat, kann nun die eingebauten Session-Upload-Progress-Funktionen nutzen, aber das ist ein anderes Thema)
Die relativ schlanke Extension APCu (GitHub-Repository), in der nur noch die übrig gebliebenen Funktionen wie z.B. apc_store() und apc_fetch() enthalten sind, wurde dann noch etwas verbessert. Vorher war das unmöglich da die komplizierte große APC-Extension nur schwer wartbar war.
Die Version 4.0.1 von APCu sollte unbedingt vermieden werden da sie nicht APC-kompatibel ist, es gab da einen Bug. Also 4.0.0 oder besser >=4.0.2 verwenden. Die Installation ist denkbar einfach. Falls PHP 5.5 über das Paketmanagement von Ubuntu installiert wurde reicht ein einfaches:
sudo apt-get -V install php5-apcu
Oder via PECL installieren:
OpCache in PHP 5.5
Ende Januar wurde es von Zeev Suraski, dem Chef von Zend, angekündigt und am 13. Februar in die Tat umgesetzt: Der Quellcode des Opcode Caches von Zend mit dem Namen Optimizer Plus wurde auf GitHub veröffentlicht und unter die PHP-Lizenz gestellt, mit dem Ziel es in den PHP-Kern einzubauen. Der Zeitplan war aber sehr problematisch, denn eigentlich war für März die neue PHP-Version 5.5 geplant. Doch der Code ist bereits seit Jahren im Closed-Source-Einsatz bei Zend, ziemlich stabil, und es wäre das neue Feature in der neuen Version.
Release und Voting
Doch dafür muss der jährliche Release-Zyklus gedehnt und das Release um wenige Monate verschoben werden. Die Diskussion ging einige Wochen, auch bereits vor der eigentlichen Veröffentlichung, und ein Voting im RFC sollte entscheiden. Doch auch das Voting war problematisch, denn es gab 3 Möglichkeiten: Release mit PHP 5.5 incl. Verzögerung von wenigen Monaten, Release mit PHP 5.5 nur ohne Verspätung sprich 5.6, und die dritte Möglichkeit war keine Integration in den Kern.
APC „Potential cache slam averted for key XXX“
Erst gestern bin ich wieder auf den folgenden „Bug“ (bzw. Feature) gestossen und musste den Workaround raussuchen, deshalb schreibe ich ihn jetzt hier nieder, vielleicht stösst ja auch jemand von euch mal darauf.
Es geht um die allseits beliebte APC Extension. Seit Version 3.1.3 (von August 2009) gibt es in APC einen Schutz gegen potentielle Race-Condition-Probleme bzw. einem Deadlock bzw. einem Cache-Slam (so genau weiß ich das auch nicht 😉 ). Es geht jedenfalls darum dass viele parallele bzw. aufeinander folgende APC-Schreibbefehle (apc_add()/apc_store()…) ein Problem auslösen können, und deshalb wurde eine Sperre eingebaut sodass auf einen Key nicht innerhalb kurzer Zeit mehrfach schreibend zugegriffen werden kann. Doch je nach Last auf der Maschine bzw. dem eingesetzten Script kann das durchaus vorkommen, und dann gibt es den Fehler:
High Performance: Caching (reloaded) mit PHP
Gastartikel von Oliver Sperke.
Ich bin 35 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.
Nach langem Arbeiten an einem Projekt fängt der ambitionierte Entwickler an, zu testen, wie sich seine dynamische Internetseite unter Last verhält. Da ja jeder von uns von Millionen Besuchern träumt, will man natürlich auch wissen, wie sich Millionen von Besucher anfühlen und ob unser „kleines Kunstwerk“ davon genau so begeistert wäre wie wir. Dynamische Webseiten sind toll, allerdings hat der gemeine Internetserver ein großes Problem damit. Die Erzeugung ist meist sehr aufwendig. Daten müssen aus Datenbanken geholt werden, Berechnungen wollen berechnet werden und Blogeinträge müssen wie Blogeinträge aussehen.
Seit Jahren hat sich eine simple Technik etabliert, die diese gequälten Webserver entlastet. Jeder fortgeschrittene Entwickler kennt und liebt sie, weil sie so schön einfach und universal einsetzbar ist: *trommelwirbel* Das Caching *tusch*. Da aber Caching an sich ein uralter Hut ist, will ich Euch zeigen, wie Ihr evtl. Eure Performance mit minimalen Änderungen mehr als verdoppeln könnt.
Am Anfang war der Benchmark
PHP beschleunigen mit dem APC
Frameworks im Allgemeinen sind eine sehr tolle Sache. Sie bieten eine Menge Klassen und Funktionalitäten, um einem die Arbeit zu erleichtern. Viele Teile eines Frameworks kann man auch einzeln nutzen, und diese sind häufig auch recht schlank gehalten. Kernkomponenten jedoch, wie in diesem Beispiel das MVC-Konzept des Zend Frameworks, neigen dazu, recht viele Funktionen mitzubringen, die man evtl. garnicht alle benötigt. Das hat zur Folge, dass viele Dateien geladen werden, für die der Webserver immer auf die Festplatte zurückgreifen muss. Das selbe gilt natürlich auch für große Projekte, die kein Framework einsetzen, aber sehr viele oder große Scripte verwenden und gut besucht sind. Und wir alle wissen, dass Festplatten noch immer (auch SSDs) eine der langsamsten Komponenten in einem Rechner sind.
Aber es gibt Abhilfe: Caching! Als erstes macht es natürlich viel Sinn, im PHP-Code selbst Daten und Objekte zu cachen. Immer wiederkehrende, sich selten ändernde Datenbank-Ergebnisse zum Beispiel. Diese kann man entweder in der Session speichern, oder in memcached-Instanzen, oder oder. Über Zend_Cache und die verschiedenen Backends hatte ich ja auch bereits geschrieben.
Zweitens macht es aber auch sehr viel Sinn, die PHP-Scripte selbst zu cachen. Erstens liegen sie auf der langsamen Festplatte, und zweitens liegen sie dort ja als Textdateien. Wenn PHP aufgefordert wird, sie auszuführen, erstellt es erstmal aus dieser Textdatei einen Bytecode. Dieser Bytecode ist maschinennah, und ist dann ausführbar. Natürlich kostet dieses Übersetzen Zeit. Im Normalfall wird bei jedem Aufruf das Script neu übersetzt.
Bytecode-Caches, wie APC (Advanced PHP Cache) einer ist, speichern diesen Bytecode zwischen, nämlich im schnellen Arbeitsspeicher. Statt also bei jedem Request 50 Zend-Framework-Klassen zu übersetzen, werden sie einfach aus dem Bytecode-Cache genommen, das bringt Speed!
Der APC soll in (ferner?) Zukunft direkt mit PHP ausgeliefert werden. APC ist aktuell eine PHP-Extension, die man einfach herunterlädt, in der php.ini aktiviert, und dann bekommt man schnellere Webseiten, man muss nicht eine Zeile PHP-Code ändern. Was kann es schöneres geben?
Hier die Installation unter Ubuntu:
sudo apt-get install php-apc
fertig! Wenn man nun eine phpinfo Seite aufruft, ist dort ein Abschnitt über APC enthalten.
Man kann diese Parameter natürlich alle ändern, vor allem die Cache-Größe sollte man anpassen, damit auch alles reinpasst. Es gibt außerdem ein kleines apc-Admin-Script, mit dem man den aktuellen Stand des Caches anzeigen lassen kann (das ist im Fall von Ubuntu unter /usr/share/doc/php-apc/apc.php.gz zu finden, oder aber im Quell-Archiv der PECL). Dieses php-Script einfach an ein sicheres Verzeichnis des Webservers kopieren, und man erhält beim Betrachten:
Um die Illusion zu zerstören: Man kann die Ausführungszeit mit dem APC nicht um 99% reduzieren. Aber die 2-5 fache Performance kann man durchaus rausholen, und das mit nur 5 Minuten Arbeit!
Übrigens kann man APC nicht nur zum Cachen des Bytecodes verwenden, nach der Installation kann man auch Objekte, und Daten etc innerhalb der PHP-Scripte im Arbeitsspeicher cachen. Dazu gibt es Funktionen wie apc_store(), apc_fetch usw. Mehr dazu im PHP-Manual.
Neben APC gibt es natürlich auch noch andere Bytecode-Caches. Darunter sind XCache, eAccelerator und Zend Platform/Zend Server.