Tagesarchiv für den 21. August 2006

PHP Bug

Montag, den 21. August 2006

A propos PHP: seit über eineinhalb Jahren gibt es da den Bug #31892, welcher das merkwürdige Verhalten der Umgebungsvariablen PHP_SELF bzw. PATH_INFO in Abhängigkeit der php.ini-Einstellung cgi.fix_path_info beschreibt. Ein entsprechendes Patch ist nicht wirklich komplex (siehe mein Kommentar auf der PHP-Fehlerseite), aber scheinbar verlassen sich schon so viele PHP-Anwender auf diesen Fehler, dass dessen Beseitigung offenbar auch nicht (mehr) in Frage kommt.

Auch bei dem PHP-Update Ende letzter Woche haben wir (wie immer *seufz*) erst unser eigenes Patch einspielen müssen…

Falls jemand an den Patches interessiert ist, ich habe diese an die jeweils aktuelle PHP-Version angepasst: patch-31892-4.4.4.diff, patch-31892-5.1.5.diff.

Schneller!

Montag, den 21. August 2006

Ein Kunde hat ein Problem: seine Bildergallerie läuft zu langsam. Es handelt sich dabei um die allseits beliebte Gallery2, die besagter Kunde mit den neuen ACL-Features nutzt. Das Problem in der Praxis: zur sauberen Umsetzung des Zugriffsschutzes werden auch Thumbnails nicht einfach nur als Links auf statische Bilder ausgegeben, sondern durch ein PHP-Script welches erst noch die benötigte Berechtigung zum Abruf des Thumbnails prüft. Ruft man also eine Gallerie-Übersicht auf, so erfolgt für jedes einzelne Vorschaubild ein PHP-Aufruf. Immerhin werden die Thumbnails innerhalb von Gallery2 gecached, also nicht jedes mal neu skaliert. Trotzdem ist der Aufbau der Seite auf diese Art und Weise doch eher zäh.

Nun - diesen Kunden haben wir zuerst auf einen etwas weniger ausgelasteten Webserver verschoben, aber offensichtlich ohne viel Performance bei seiner Gallery2 hinzuzugewinnen. Man muss dazu sagen, dass wir intern zur Umsetzung unserer “Security Policies” unter anderem auf die Eigenentwicklung seCGI setzen, die wir auch als Open Source Software veröffentlich möchten (siehe Blog-Eintrag dank informatik). seCGI sorgt dafür, dass jedes PHP-Script mit den Rechten des tatsächlichen Benutzers ausgeführt wird, und nicht mit den Rechten der Webserver-Software. Die neuesten Bugs in PHP (4 und 5) bestätigen wieder einmal, dass man sich nicht alleine auf open_basedir & Co. verlassen sollte.

Das Ergebnis ist nun, dass wir endlich mal umsetzen was schon länger auf der Wunschliste steht und halbfertig im Testsystem herumliegt: FastCGI. Für solche “Spezialkunden” werden dann 2-3 exklusive PHP-Prozesse unter deren eigener User-ID vorbereitet, welche wie mod_php alle Vorteile der Code-Optimierung und -Caching nutzen können. Da diese zusätzlichen Prozesse einen Teil der Server-Ressourcen exklusiv binden, wird FastCGI vorerst nur für wenige spezielle Anwendungsfälle eingesetzt werden. Mittelfristig soll FastCGI als Alternative zum “normalen” seCGI wahrscheinlich gegen einen geringen Aufpreis für jedermann nutzbar sein.