RackBlogger

… muss auch mal sein.

Die letzten Tage waren geprägt vom Jahresabschluss 2005 (ich freue mich schon auf den Steuerbescheid *g*), von einem überraschend entspannten Wochenende, und einem weitaus produktiveren Montag als erwartet.

Die eine Webanwendung ließ sich gegen 18:00 erfolgreich messen und überraschte mit ihrer Reaktionsgeschwindigkeit (innerhalb weniger als 50 Millisekunden werden nun spezielle Events von verschiedenen Servern im Browser dargestellt - asynchron und browserunabhängig).
In der anderen Webanwendung (C++) habe ich die Zeitstempel des Logfiles von Sekunden- auf Mikrosekunden-Genauigkeit umgestellt, somit einen Performance-Engpass enttarnt und die Verarbeitungsdauer für eine HTTP-Anfrage von max. 1000ms auf rund 8 ms reduzieren können. So gehört sich das.

Durch einen bislang unbekannten Fehler ließ sich eine in Entwicklung befindliche Software unter Microsoft Windows nicht korrekt ausführen (ich muss dazu sagen, dass das Programm unter allen üblichen Betriebssystemen lauffähig ist sein soll). Ich habe den Fehler eben auf die Low-Level-Netzwerkfunktionen reduzieren können - um genau zu sein kam select() nicht mit dem übergebenen fd_set zurecht.

(Sorry, wenn ich nun ein paar weniger Programmier-affine Leser langweile:)

Die Lösung steht sogar in der MSDN-Doku, man muss sie nur suchen finden:

Internally, socket handles in an fd_set structure are not represented as bit flags as in Berkeley Unix. Their data representation is opaque. Use of these macros will maintain software portability between different socket environments.

Und da liegt auch schon der Hund begraben: für die FD_SET-Makros habe ich eigene Ersatzfunktionen programmiert, weil die meisten vordefinierten Makros (z.B. von der glibc) einen Buffer Overflow ermöglichen würden.
Da ich unter Unix-Systemen aber mit Bitmasken herumrechne, komme ich unter Windows mit einem völlig anders gearteten fd_set-Array nicht zurecht. Naja, Problem erkannt, Problem beseitigt, und schon geht’s mir wieder etwas besser.

Es ist vollbracht: mod_fastcgi läuft zusammen mit unserer seCGI-Wrapper-Umgebung. Auf Deutsch: für spezielle Anwendungsfälle können wir nun gezielt bei einzelnen Kunden die PHP-Scripts über mod_fastcgi ausführen lassen - ohne dabei auf die gewohnte sichere Ausführungsumgebung zu verzichten. Ein kleiner Eintrag in der httpd.conf genügt hierfür.

Im Hintergrund hat das schon etwas Arbeit mit sich gebracht… das mod_fastcgi-Modul musste angepasst werden, damit es die “richtigen” Daten über den Benutzer etc. erhält und möglichst nahtlos in die bisherige Konfiguration integrierbar ist. Aber der Aufwand hat sich gelohnt. Manche Scripts laufen somit bis zu 10x schneller

Da ein Server bei zu großzügiger Konfiguration aber auch schnell ins Schwitzen geraten kann, wird mod_fastcgi vorerst nur für spezielle Websites eingesetzt, die ohnehin schon eine höhere Last verursachen. Für kleine Websites mit gelegentlichen Script-Aufrufen wäre fastCGI sogar langsamer als der aktuelle PHP-CGI-Aufruf (der Starten der fastCGI-Prozesse dauert etwas länger als ein PHP-CGI-Aufruf).

Die Tests sind jedenfalls heute abgeschlossen worden, und morgen wird das ganze dann für die ersten Websites freigeschaltet. Ich freu’ mich schon…

Ein etwas größeres Tuning an den Mailman-Mailinglisten ist nun auch (fast) abgeschlossen. Wenn nun alles stabil in der Testumgebung läuft, werden die bestehenden Mailinglisten in Kürze umgezogen.
Es sei nur so viel gesagt: Mailman lässt sich auch prima in Exim integrieren (wer braucht schon Postfix), virtuelles Hosting mit gleichnamigen Mailinglisten in unterschiedlichen Domains ist nur unmöglich solange man nicht den Code patcht und nun sind auch alle Prozesse automatisierbar.

Eine Google-Suche nach diesem Begriff führt zu keinem einzigen Treffer. Hat denn noch niemand versucht sowas zu programmieren?

Gerade so etwas müsste doch mit einer entsprechend generalisierten “Ur-Syntax” in jeden beliebigen SQL-Dialekt überführbar sein… Ich glaube, ich werde mal meine alten Aufzeichnungen zu Yacc herauskramen *Ärmel hochkrempel*

Komische Sachen gibt’s…

Setzt zufällig noch jemand irgendwo FPDF ein und hat die Möglichkeit, in der php.ini den Eintrag expose_php auf Off zu setzen?

Sobald ich das hier mache, wird als Content-Type nur noch text/html statt application/pdf ausgegeben. Seeeehr merkwürdig…

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.

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.