Das Fotolia ein Problem mit der Performance hat, ist einschlägig bekannt ;-) Fotolia ist ein PHP Projekt und demonstriert geradezu auf tragische Art und Weise, wie man es nicht machen sollte. Es kämpft mit riesigen Datenmengen und extrem guten Zugriffszahlen - ich habe den Eindruck die Jungs (oder der Server) von Fotolia sind schlichtweg überlastet.
Bei meiner aktuellen Bild-Recherche auf Fotolia ist mir aufgefallen, das Fehlermeldungen bei Fotolia direkt auf der Webseite ausgegeben werden - ist das wirklich gut? Definitiv Nein - Fehlermeldungen haben auf einer Liveseite nichts zu suchen.
Es kann ganz schön gefährlich sein, denn durch SQL-Statements die direkt auf der Webseite ausgegeben werden, kann man ganz schnell verraten, mit welchen Frameworks oder Bibliotheken man arbeitet, wie die Datenbankstruktur aussieht - uvm…
Nachfolgend ein paar Tipps, wie man es besser machen kann.
Böse Buben können das ganz schnell ausnutzen - gerade bei prominenten Seiten. Wie kann man Fehler besser abfangen? Ratsam ist es auf jeden Fall in der php.ini zu erst einmal display_errors auf “Off” einzustellen. Damit Fehler trotzdem aufgefangen werden können, ist es eine gute Idee log_errors mit “On” anzuschalten.
Ein kompakte Übersicht wichtiger Einstellungen findet man in einem PDF zum Thema “Web-Technologien – Thema PHP Sicherheit“. Dort wird auch ein Beispiel gelistet, wie man die PHP Konfiguration über Apache-Direktiven anpassen kann. Das ist sehr praktisch, wenn auf einem Server mehrer Projekte auf unterschiedlichen Domains gehostet werden. Dann kann man z.B. ein eigenes error_log für jedes Projekt im Virtual Host definieren.
Okay, soweit zu PHP - Wie sieht es denn mit Datenbankfehlern aus? Gerade für MySQL lohnt sich ein ausführlich implementierter Error Handler, der ein aussagekräftiges Log schreibt. Zusätzlich ist es ratsam, auf den MySQL Mechanismus zum Protokollieren langsamer Queries zurück zu greifen - PHP Performance beschreibt das im Artikel “Langsame MySQL Statements finden” ausführlich.
Aber was tun im konkreten Fehlerfall? Aus meiner Sicht gibt es 3 gute Möglichkeiten:
- Auf eine statische Seite weiterleiten, die einen allgemeinen Fehler anzeigt. Etwa in der Art “Im Zuge von Wartungsarbeiten wird unsere Webseite gerade überarbeitet. Bitte entschuldigen Sie mögliche Ausfälle, unser Portal steht Ihnen bald überarbeitet wieder zur Verfügung” - Das klingt ziemlich schön geredet und beschreibt keinen sporadisch auftretenden Fehler, sondern eine geplante Wartunsarbeit. Wer ehrlich sein möchte ist vielleicht mit folgendem Satz besser bedient: “Gerade ist ein interner Fehler aufgetreten - Sollten Sie diese Meldung häufiger angezeigt bekommen, wäre es nett, wenn Sie dies unserem Support melden würden. Wir verbessern den Service und die Stabilität unseres Portals fortwährend.”
- Den HTTP Status Code 500 zurückliefern. Einen internen Server-Fehler zeigt man mit dem senden des 500er Statuscodes am noch am ehesten protokollkonform an. Diese Art der Fehlermeldung war im Zuge von CGI und dem Einsatz von Perl mal an der Tagesordnung, wird momentan aber als veraltet und unschön verschrien. Ich finde es aber immer noch besser, als irgendwelches nichts sagendes Blabla oder grässliche PHP und MySQL Fehler anzuzeigen.
- Eine leere Seite zurückliefern. Zugegebenermaßen nicht die feine englische Art, aber so gelangen keine internen Informationen an den Benutzer. Ein die() kann sich jeder Errorhandler aus den Rippen leiern. Dem Besucher der Website ist übrigens völlig egal, ob er eine weiße Seite, einen HTTP Statuscode oder eine statische Seite mit Blabla zu sehen bekommt - er will nur, das alles funktioniert - egal wie. Warum es nicht funktioniert, kann man ohnehin nicht so erläutern, das es ein Ottonormalverbraucher kapiert.
