In meinem ersten Teil der hier vorliegenden Serie, die sich an fortgeschrittene Web-Developers richtet, habe ich bereits einige fundamentale Fehler aufgezeigt, die auf Partyguide anzutreffen sind. Diese Kritik liesse sich ohne weiteres auf viele andere Web-Projekte übertragen – auch Sites von mir, die mehrere Jahre auf dem Buckel haben, könnten an der einen oder anderen „Krankheit“ leiden. Ich versuche aber, ständig an meinem Code zu feilen und ihn zu verbessern. Deshalb sind die meisten Sites, die ich dieses Jahr für Kunden erstellt habe, denn auch mit Hilfe von CSS2 realisiert. Das altgewohnte „Tabellendesign“ konnte ich so erfolgreich in Pension schicken.
Den vorigen Artikel habe ich auch an die Verantwortlichen geschickt, wurde aber mit meinem Votum aber nicht ganz ernst genommen:
Was clientsite programming anbelangt… Ist 2. Priorität. Erste Priorität ist, dass die SQL Statements/Serverkonfigurationen so sind wie sie sollten.
Aber vielleicht bist du ja noch zu unerfahren um irgendwie was über „prioritäten“ zu wissen ;-)
Quelle: Mail von Philippe Knaus vom 28. Dezember 2005
„If it ain’t broken, don’t fix it“ oder schärfer ausgedrückt: „Es läuft ja, wo ist das Problem?“. Der Unterschied zwischen laufen und performant laufen kann aber gross sein. Meine These lautet deshalb: Bei Partyguide werden unnötigerweise Ressourcen verschwendet, weil man lieber neue Features einbaut, anstelle den bestehenden Code zu optimieren (Flickr.com, mein momentaner Star am Web-Himmel kriegt beides unter den Hut – dort sitzen aber auch Profis dahinter).
Übrigens: Wikipedia vermeldet zum Thema ‚Optimieren‘ treffenderweise:
In computing, optimization is the process of modifying a system to improve its efficiency.
Quelle: Optimization (computer science)
Im zweiten „Hands-on-Partyguide“-Teil habe ich wieder zwei Don’ts gefunden, die als gutes Lehrstück herhalten.
On-The-Fly Kuchendiagramm
Im Laufe der Zeit hat PHP gelernt, bei der Erstellung von Grafiken behilflich zu sein. Partyguide nutzt dies aus, um ein Kuchendiagramm zu generieren (s. rechts). Benutzer mit einem Profil sehen auf diese Weise sofort, wieviele Bewertungen („Wow“, „Herzig“, „Nicht mein Typ“) sie (relativ) erhalten haben.
Das Generieren von Grafiken ist speicher- und CPU-intensiv. Während ich das letzte Mal den Fokus eher auf Traffic-Verminderung gelegt habe, geht es in diesem Abschnitt darum, den Performance-Hunger von PHP-Scripts zu mildern.
Das Kuchendiagramm wird bei jedem Aufruf des Profils einer Person angezeigt. Dazu werden die von anderen Benutzern erhaltenen Bewertungen aus der Datenbank gelesen, aggregiert und an ein PHP-Script weitergegeben, das aus den übergebenen Daten ein Kuchendiagramm hervorzaubert:
<img src="user_details_diagramm.php? rate1=21.276595744681& rate2=125.95744680851& rate3=212.76595744681" width="100" height="100" border="0" align="left">
Int oder Float?
Auf den ersten Blick fällt dem geübten Auge auf, dass die Zahlen recht lang daherkommen. Muss das so sein? Nein. Denn schliesslich benötigt ein Kuchendiagramm keine Präzision auf über 10 Nachommastellen genau. Optimal wäre es, wenn das Script, dass die URL generiert, die Zahlen gleich in Prozente umwandeln würde. Dann würden sage und schreibe NULL Nachkommastellen reichen, um eine Grafik herzuzaubern.
Übrigens – die URL kann man ohne weiteres in eigene Projekte einbinden und so Kuchendiagramme nach eigenem Gusto anzeigen. Ob dies viel bringt, ist eine andere Frage … Ich jedenfalls stelle das obige Bild genauso dar – ich binde es direkt vom Partyguide-Server ein. Mal schauen, wie lange es geht, bis die Entwickler einen Referer-Filter einbauen *smile*
Statisch oder Dynamisch?
Abgesehen von zu langen Fliesskommazahlen stellt sich mir die viel brennendere Frage, ob man diese Kuchendiagramme wirklich bei jedem Aufruf dynamisch generieren sollte? Wäre es performance-mässig nicht deutlich intelligenter, auf eine statische Grafik zu verweisen?
Dies ist ohne weiteres machbar – und würde den Web-Server entlasten. Anstelle ein PHP-Script aufzurufen, dies durch den PHP-Parser zu jagen, die GDlib (oder was für eine Grafik-Bibliothek auch immer bei Partyguide im Einsatz steht) zu starten, das Bild zusammenzusetzen und die Binärdaten zum Client zu senden würde es ausreichen, wenn Apache ein im Filesystem liegendes GIF oder PNG an den Browser zurückzusenden.
In – sagen wir – 80% der Fälle ist es nämlich gar nicht nötig, das Bild neu zu berechnen, weil das Profil keine neuen Bewertungen erhalten hat. Zudem verändern sich die Diagramme von Accounts mit sehr vielen Bewertungen auch weniger rasch – wenn zu 1000 Bewertungen eine weitere dazu kommt, bedeutet dies Änderungen im Promillebereich, die bei einer derart kleinen Grafik kaum zu erkennen wäre.
Ich würde deshalb ein PHP-Script schreiben, dass ausschliesslich beim Eingehen einer neuen Bewertung aktiv wird. Das Script würde durch eine User-Interaktion („Bewertung“) angestossen und würde das bestehende, statische GIF, das mit der User-ID irgendwo Filesystem des Servers liegt, löschen und sofort darauf ein neues Bild aus den neuen Daten generieren. Apache würde es einem danken.
GET-Variablen
Bei weiteren „Untersuchungen“ am HTML-Code ist mir zudem noch etwas aufgefallen. Die Entwickler scheinen keiner konsequenten Linie zu folgen, wie GET-Variablen benannt werden. Für mich ist eine konsequente Durchsetzung von Namenskonventionen das A und O des Programmierens. Wer dies als lästige Erfindung von Klugscheissern empfindet, sollte sich einen anderen Job suchen. Insbesondere gerade wenn man im Team an einem Projekt arbeitet, sind solche Konventionen unbedingt notwendig:
URL, um das Profil eines Users anzuzeigen:
http://www.partyguide.ch/user_details.php?my_pic_member_id=30689
Andererseits verwendet man innerhalb dieser Rubrik dann etwas völlig anderes:
URL, um hochgeladene Bilder eines Profiles anzuzeigen:
http://www.partyguide.ch/user_details_fotos.php?username=mad4you
Fürchterlich! Einerseits heissen die GET-Variable unterschiedlich, bezeichnen aber schlussendlich denselben user, andererseits scheint man sich bei Partyguide auch nicht im Klaren zu sein, ob man nun jetzt mit dem Usernamen arbeiten will (der törichterweise Umlaute und Sonderzeichen enthalten kann), oder doch der eindeutigen User-ID, die wohl dem Inhalt einer Tabellenspalte entspricht.
Verräterische Cookies
Dieser Punkt hier hat für Partyguide überhaupt keine Auswirkung auf Bandbreite oder Performance der Server. Erwähnenswert ist er aber allemal.
Die Entwickler von Partyguide haben nämlich wieder einmal einen Tritt ins Fettnäpfchen gewagt und zeigen, dass sie sicherheitstechnisch kaum auf dem Laufenden sind. Ich frage mich gar, ob man überhaupt sensibilisiert ist? Wohl kaum …
Jedenfalls haben die Vollprofis dort entschieden, dass das Account-Passwort der Benutzer im Klartext auf der Festplatte der Anwender gespeichert wird (geniales Hilfsmittel: Cocoa Cookies 0.7):
.partyguide.ch sess_psw / ********
Dies geschieht dann, wenn der User ‚Autologin‘ angewählt hat und sich so nicht bei jedem Besuch mit seinen Zugangsdaten authentifizieren muss. Man kann einwenden, dass dies auf Privat-Computern keine grosse Rolle spielt – doch mir ist es nicht wohl, wenn eines meiner Passwörter in Text-Dateien auf dem Computer herumliegt und nur darauf wartet, von einem Trojaner etc. ausgelesen zu werden. (Ich habe einen Mac, weshalb ich mir deutlich weniger Sorgen machen muss als Windows-Anwender).
Auch wenn man die Autologin-Funktion nicht verwendet, steht man mit heruntergelassenen Hosen da. Denn ist man einmal eingeloggt, wird das Passwort bei jedem Request an .partyguide.ch mitgesendet. Das schreit förmlich nach einer fiesen Hacker-Attacke, um das Passwort im Klartext abzufangen. Mittel und Wege dazu gibt es allemal – kommt das HTTP-Paket bei einem Menschen mit bösen Absichten vorbei, ist es passiert.
Vielleicht sollte sich die Verantwortlichen doch überlegen, zumindest einen MD5-Hash des Passwortes zu generieren und diesen auf den Rechnern der Anwender als Cookie zu hinterlegen. So ist immerhin die Gefahr gebannt, dass Profis mit einem Blick erkennen, wie das Passwort im Klartext lautet. Dass damit aber der Missbrauch nicht ausgeschlossen ist, bleibt klar – da man den Hash vorliegen hat, kann man sich auch in Zukunft frischfröhlich anmelden.
Weitere Beispiele folgen garantiert – to be continued …
