Blog

Plupload. Ist ein Multifile Uploader. Ich bin dank Weri darauf aufmerksam geworden. Für Drupal gibt es ja bereits den Image_fupload, welcher auf dem SWF Upload basiert. Leider hat der Probleme mit Proxy Servern und so ist das sehr oft nicht wirklich eine Lösung. Ich habe nach wie vor eine offene Pendenz… 🙁

Da ein neues Projekt ebenfalls einen solchen Multifile Uploader benötigt, habe ich ein wenig recherchiert. HTML 5 unterstützt das out of the box. Wäre ja super genial… aber leider wird das noch nicht so breit unterstützt, und steckt noch in den Kinderschuhen.

Die Lösung: Plupload. Kann mit Flash, Silverlight und sogar HTML 5 umgehen. Mal schauen, ob der Uploader Massentauglich wird… dann gibts auf jeden Fall ein kleines Drupal Modülchen 😉

CacherouterIst nicht eigentlich ein Cache sondenr eben der Cacherouter. Der Cacherouter entscheidet, wo die Daten gespeichert werden. Ist der Cacherouter einmal eingeschalten, dann kann man problemlos von einem Cachingmechanismus zum anderen wechseln.
Um den Cacherouter richtig zu verstehen, muss man verstehen, was Drupal Cached; auch das ist simpel. Drupal Cache grundsätzlich Objekte oder ganzer HTML Code. Nehmen wir zum Beispiel eine Drupal Seite. Diese muss bei jedem Request neu gebaut werden, dazu wird die Datenbank entsprechend belastet und es entsteht eine Vielzahl an Queries. Endresultat ist der fertige HTML Code, welcher an den Besucher geschickt wird. Ist der Drupal Cache angeschalten, dann wird dieses HTML so wie es ist in die Datenbank gespeichert. Kommt der nächste Besucher, so kann lediglich dieses Stück HTML abgeholt werden und ausgeliefert werden.

Der Cacherouter entscheidet jetzt, wo genau dieses Stück HTML Code abgespeichert werden soll. Es wird nicht nur HTML iim Cache abgelegt sondern auch PHP Objekte/Arrays, welche vorher serialisiert werden.

Die Konfiguration des Cacherouters ist sehr einfach und es gibt diverse Beispiele auf der Cacherouter Projektseite.

APC als OP Cache
APC stellt sich als sehr unproblematisch heraus und lässt sich sehr schnell einrichten. APC ist primär ein OP Cache. Ein OP Cache speichert den interpretierten PHP Code, so dass der nicht bei jedem Aufruf neu geladen und interpretiert werden muss -> die CPU wird sich freuen. Installation von APC ist problemlos -> einfach mal Googeln.

APC und Cacherouter
Über den Cacherouter lässt sich APC auch als Objektcache verwenden, will heissen der HTML Schnippsel, bzw. das serialisierte Objekt wird nicht in der Datenbank gespeichert sondern im APC Memory. Daraus resultieren weniger Zugriffe auf die Datenbank. Auf der Projektseite des Cacherouters steht auch, wie man Cacherouter konfigurieren kann… sollte eigentlich verständlich sein.
Unter gewissen Umständen lässt sich APC nicht als Objektcache einsetzen. Wenn FastCGI eingesetzt wird und persistente Worker Prozesse verwendet werden, dann hat jeder dieser Prozesse seinen eigenen APC Memory -> APC kann daher nicht als Objektcache eingesetzt werden.

Memcache und Cacherouter
Memcache ist der grosse Bruder von APC und wird in vielen Projekten eingesetzt (unter anderem auch Facebook). Über den Cacherouter lässt sich Memcache gleich wie APC verwenden, will heissen, fertige HTML Schnippsel bzw. serialisierte Objekte werden im Memcache abgelegt. Der Vorteil von Memcache gegenüber APC ist jedoch, dass er nicht an einen Rechner gebunden ist: Ich könnte also einen dedizierten Rechner haben, welcher nur als Memcache dient und welchen ich von meinem Applikationsserver aus ansteuere.
Nehmen wir zum Beispiel ein Loadbalancing mit mehreren Webservern. Würden wir auf APC setzen, dann hätte jeder Server seinen eigenen Cache -> Wirkung ist nicht so hoch. Wenn wir jedoch einen dedizierten Memcache Rechner haben, welcher von allen drei Webservern verwendet wird ist die Effizienz um einiges höher.
Auch Memcache lässt sich über Cacherouter problemlos ansteuern. Memcache ist per se ein wenig langsamer als APC, was sich jedoch wierum relativiert, wenn man eben mehrere Webserver einsetzt.

Probleme
Klingt alles relativ einfach, aber es gibt auch ein paar Problemchen, welche mir in den letzten Wochen begegnet sind, zu denen ich zum Teil Lösungen gefunden habe, zum Teil nicht:

• APC mit FastCGI kann nicht als Objekt Cache genutzt werden, da jeder Prozess seinen eigenen Speicher hat.
• Cacherouter, Memcache und FastCGI ist nicht ganz ohne. Hier kommt nach wie vor ein 500er Error. Da muss wohl der Hoster noch ein wenig ran.

Weitere Möglichkeiten
Es gibt noch diverse andere Caches:

• Varnish (Ist ein Reverse Proxy)
• Squid
• xCache
• Zend Server
• und und und

Zu Varnish komme ich noch. Da bin ich noch dran, den zum Laufen zu bringen, bzw. Drupal (pressflow) dazu, dass es "gevarnished" wird.

Ich habe noch ein wenig weiter rumgespielt. So Drupal Profiles sind schon noch recht cool. Würde mich über Feedback freuen.

Download ist hier.

Das Profil lässt sich dann ganz normal installieren:

Inhaltstypen, views usw. Ich bin jetzt noch ein wenig am Dinge sammeln, welche so ein Profil ausmachen würden, damit man ein Picture Drupal hat, welches einfach nur eine Fotogalerie ist.

Drupal ist nicht gerade sparsam, wenn es an die Anzahl von Queries geht. Hier eine kleine Auflistung, wo es "Query-Schleudern" gibt.

• Mobile Tools: Eigentlich ein praktisches Tool, aber es hat noch ein paar Problemchen. Wenn man viele Rollen hat, dann werden eine Unmenge an Queries generiert. Ich habe da je nach Seite zwischen 80 und 200 Queries gezählt.
• Node Relationen: Das ist etwas super praktisches. Man kann alle möglichen Sachen damit abbilden, doch wie sieht es mit der Performance aus. Als ganz simples Beispiel: Einen Artikelnode und ein Bildnode. Beides wird über eine Noderelation verbunden. Um den Artikel darzustellen, muss zuerst node_load für den Artikel aufgerufen werden und dann entsprechend noch node_load für das Bild. Wenn jetzt auf einer Seite 10 Artikel sind, dann summiert sich das ziemlich schnell auf.
Es ist zwar extrem praktisch node_load zu verwenden, aber man sollte dabei die Performance im Hinterkopf halten.
• Übersetzungen: Übersetzungen über die T Funktion t(), werden hauptsächlich im Backend verwendet. Jede t() Funktion bedeutet eine DB Anfrage. Auch das kann sich aufsummieren.
• Links: Links welche über die l() Funktion gebaut werden, verlangen ebenfalls eine DB Abfrage, da geschaut wird, ob es einen Alias gibt. Dabei handelt es sich um eine ganz einfache Select Abfrage, aber es ist nicht die Komplexität, sondern die Masse. In einem Link Block finden sich schnell mal 30 Links, was bedeutet, dass 30 Abfragen gemacht werden müssen.
• XML Sitemap: Entpuppte sich als wahrer Bremsklotz. Noch ist mir nicht ganz klar, was hier genau die Ursache ist, da ich noch nicht dazu gekommen bin, das Modul genauer zu untersuchen. Die XML Sitemap generiert ein XML, welches eigentlich alle Links der Seite enthält und schickt dieses XML an Suchmaschinen, damit der Inhalt optimal indexiert wird.
Aus irgend einem Grund führte die Generierung dieses XMLs zu extremer CPU und Datenbanklast (Spitzen von 3000 Queries pro Sekunde), bis der Server ein Timeout gab.

Viele dieser Abfragen lassen sich durch Einsetzen eines Caches abfangen. Cache ist King! Nehmen wir zum Beispiel einen nochmals unseren Links Block mit den wichtigstens Links im Footer (wie z.B. auf der Skype Seite). Dieser Block ist auf jeder Seite identisch. Ohne Blockcache wird jedoch für jeden Link eine Datenbankabfrage nötig sein, was völlig unnötig ist. Blockcache einschalten und sicherstellen, dass der Cache für diesen Block auf "global" gestellt ist, will heissen, dass der erste User, der eine Seite aufruft, den Block generieren muss und jeder folgende dann einfach die fertige Version aus dem Cache bekommt, bis zum nächsten Mal, wenn der Cache wieder frisch aufgebaut wird (defaultmässig ist das beim Speichern eines Nodes).

Hier werden in den nächsten Tagen Wochen Beiträge zu Drupal Performance und Optimierung kommen… fangen wir doch mal mit den Basics an.

Die Modularität hat ihren Preis. Wenn man ein paar Module im Einsatz hat, dann wird eine Drupal Installation schnell einmal langsam. Es werden unmengen von SQL Queries abgesetzt, um die notwendigen Seite zusammenzustellen (einige hundert bis einige tausend). Das schlägt sich natürlich in der Geschwindigkeit nieder. Gut ist es sicher, dies zu vermeiden, was aber nicht wirklich immer möglich ist, bzw. mit Funktionseinbussen verbunden ist, denn über hook_nodeapi hat jedes Modul die Möglichkeit, beim Nodeload den Node zu modifizieren. Dadurch kann doch eine beachtliche Anzahl an Abfragen entstehen. Einige Module setzen dafür einen Cache ein, andere wiederum nicht. Das heisst: Ein node_load ist nicht ein grosser Query mit einigen Joins, sondern besteht aus vielen kleinen Queries. Das heisst, wenn jetzt auf einer Seite einige Nodes geladen werden müssen (Teaser, Übersichtsseiten, Nodeblöcke usw), dann kann sich das schnell kumulieren.

Lässt sich das ändern? Es lässt sich sicher vermeiden, indem die Module sorgfältig ausgewählt werden, aber die Grundproblematik bleibt bestehen. Die Flexibilität, welche dadurch entsteht ist dafür fantastisch.

Auswege. Liegen eigentlich beim Caching. Hier gibt es diverse Strategien, aber erst einmal gilt es, die Drupal Board Mittel zu benützen, welche für kleine Seiten durchaus ausreichend sind:

• CSS Aggregation ist ein Muss
• JS Aggregation eigentlich auch, aber führt jeweils bei deutschsprachigen Seiten zu Problemen. Also ich habe da immer Probleme mit einem File, welches nicht gefunden werden kann. Dafür gibt es ein nettes kleines Modul und schon klappts wieder.
• Drupal Cache. Der ist eigentlich super genial, aber funktioniert nur für den anonymen Besucher. In manchen Fällen mag das ausreichend sein, aber manchmal auch nicht.
• Blockcache ist mein Held.Wie weiter, wenn die Seite wächst und wächst. Es gibt diverse Module, mit welchen ich in den letzten Tagen/Wochen Erfahrungen gesammelt habe. Diese beschränken sich momentan auf die folgenden drei Module:
• Boost
• Cacherouter
• APC

Boost
Super einfach zum einsetzen. Es lässt sich auch sehr gut auf einem shared hoster einsetzen. Mein Blog hier wird von Boost unterstützt. Dabei wird die Datenbank für den anonymen Besucher entlastet, indem von der Seite eine statische Seite angelegt wird. Ein Besucher tangiert somit Drupal gar nicht, sondern wird direkt auf die statische Seite geleitet. Dies kann natürlich zu verfälschung von Statistiken führen.

Cacherouter
Ist eigentlich lediglich ein Abstraktionslayer nicht ein eigentlich Cache. Der Cacherouter kann sehr gut zusammen mit Authcache eingesetzt werden. Mit dem Cacherouter kann man jetzt bestimmen, wo sich der Cache befinden soll. Z.B. Memcache, APC, File, Datenbank usw.

Im Weiteren habe ich mir auch noch Authcache angeschaut, kam jedoch bisher noch nicht zum produktiven Einsatz. Authcache macht eigentlich etwas ähnliches wie Boost, jedoch für den Eingeloggten User. Die Seite wird als HTML gespeichert und in die DB abgelegt. Beim darauffolgenden Seitenaufruf kann der HTML fixfertig gerendert aus der DB genommen werden, zusätzlich wird die Möglichkeit geboten, Userzentrierte Blöcke mit Ajax entsprechend anzupassen.
Boost und Authcache lassen sich gut auch zusammen nützen, da man Authcache mitteilen kann, welche Rollen den Cache verwenden sollen.

Das sind relativ einfache Massnahmen. Boost läuft eigentlich auf jedem Hoster. Komisch -> bei uns haben wir noch Probleme mit dem Cache löschen?! Keine Ahnung, was da schief geht.

Obwohl ich in der letzten Zeit ultimativ beschäftigt war, Performance Probleme zu lösen, habe ich zwischendurch ein paar freie Minuten gefunden, um ein bisschen "zu spielen". Ich wollte schon lange mal mit den Drupal Installer Möglichkeiten experimentieren. So habe ich das hübsche Theme von Managing News genommen und damit eine Fotogalerie gebaut (bzw. einen Installer dazu). Wa wird beim Installieren gemacht:

• Alle nötigen Module installiert
• Ein Feature installiert, welches die Views enthält, sowie Inhaltstypen und Imagecache Presets, sowie ein paar Berechtigungen.
• Umstellung auf das korrekte Theme

Leider unterstützt Features Modul zur Zeit noch Menus. Hier bin ich dran ein bestehendes Stück Code weiterzuentwickeln, damit sich in Zukunft auch Menus mit Features portieren lassen. Alles in Allem sind Installer zusammen mit Features erst richtig cool!

Den Picmaster habe ich mal hier zum Download.

Immer noch am Performance Optimieren. Dabei habe ich mir die letzten Tage die Apache Logs vorgenommen, um Unregelmässigkeiten zu finden. Nach einem ersten Versuche diese im Texteditor auszuwerten war ich recht frustriert. Da bringt man nicht wirklich viel raus.

Die Lösung ist: awstats. Installation ist nicht ganz so einfach, aber mit einer guten Anleitung schnell durchführbar.

Dass ich so etwas mal schreiben würde, hätte ich mir nicht träumen lassen. Mittlerweile habe ich weitere 2 Wochen produktiv mit einem Linux System (Ubuntu) gearbeitet. Ist es mir verleidet? Nein. Je länger desto mehr, hat sich herausgestellt, dass ein Verständnis des darunter liegenden System umso wichtiger ist und die Arbeit umso effizienter gestaltet (wir reden hier von der professionellen PHP Entwicklung für grössere Projekte):

• Apache unter Windows ist weiterhin extrem langsam und stürzte bei mir regelmässig ab, was zeitweilen frustrierend und zeitraubend zugleich ist
• Server Probleme? Ja, es gibt Putty, doch wenn man nicht vertraut mit der Kommandozeile ist, dann wird man nicht wirklich Freude haben. Wie macht man sich vertraut damit? … sicher nicht unter Windows
Serverprobleme: Endlosschlaufen auf dem Server? Sonstige komische Serveraktivitäten? Kein Problem: Kommandozeile an, via SSH einloggen "top" und schon sieht man, was abgeht und kann via "kill" ungewollte fehlerhafte Prozesse killen.
• Drush. Ode on Drush. Schnell ein paar neue Module installieren, aktualisieren bzw. deaktvieren? "drush en admin_menu". Wunderbar. Eine ganze Installation aktualisieren? Auch das ist möglich. Aber eben nur via Kommandozeile -> supereffizient.
• Remotezugriff? Problemlos: Offener Port 22 und IP Adresse von Zielrechner und schon klappt es wunderbar und auch unter etwas langsameren Umständen.

… PHP Entwicklung: Nur noch unter Linux.

Ich habe schon Anfragen bekommen, ob ich noch am Leben bin 😉 … es ist auch echt schon ein weilchen her, seit ich das letzte Mal von mir hören habe lassen. Im Moment bin ich gerade noch extrem beschäftigt mit dem relaunch von www.schweizer-illustrierte.ch. Im Moment steht noch die Performance Optimierung an. An dieser Stelle gibt es hier demnächst auf jeden Fall ein paar Erfahrungsberichte zu APC, Boost und co. Zuerst muss jedoch die Seite einwandrei laufen.

Bis dahin bin ich weiter im Untergrund

Normalerweise arbeite ich mit folgendem System:

• Windows XP
• XAMPP (von Apachefriends)
• Eclipse
• je nach dem Subversive oder TortoiseSVN.

Das Zusammenspiel der Systeme ist eigentlich relativ gut. Ich habe zudem mal einen kleinen Ausflug zu Netbeans gemacht, was auch super gut funktioniert hat. Ich war und bin echt begeistert davon und würde es jederzeit wieder für kleinere Projekte einsetzen. Leider ist es es für grosse Projekte nicht geeignet, das es einfach zu langsam ist und noch speicherhungriger als Eclipse ist. Office 2007 und die Ribbons finde ich super. Open Office kann sicher auch alles, aber zum Arbeiten ist MS Office einfach um Klassen besser.

Linux

Gestern habe ich jetzt mal einen Linux Tag gemacht. Nachdem ich die vergangenen Wochen immer mal ein paar Minutenj in der Linux Welt verbracht habe, kannte ich mich bereits ein wenig damit aus. Ich habe es jedoch immer nur für meine kleinen Projekte für kurze Entwicklungssachen verwendet, nie jedoch im professionellen Umfeld. Daher war das gestern ein Beta Tag: Ein Tag Entwicklung mit Linux:

• Ubuntu 9.10 (mittels Wubi installer)
• Netbeans
• KDESVN
• LAMPP

Netbeans scheint auch hier die gleichen Schwächen wie unter Windows zu haben, dass es sehr langsam zu sein scheint. Eclipse habe ich aber nicht zum Laufen gebracht (und dauch nicht wirklich versucht). Apache ist vieeeel schneller und stabiler! Super. Denn, wenn auf dem Localhost entwickelt wird, dann gibt es nichts nervenderes, als eine langsame Seite. Für kleine Installationen geht es auch unter Windows zügig voran, aber für grosse Drupal Sites, kann es unter Windwos sehr langsam werden. Das mag an der falschen Konfiguration liegen?! Aber unter Linux geht es einfach. Terminal und Drush. Es läuft einfach und es ist wunderbar.

Der wichtigste Vorteil ist jedoch meiner Meinung das Verständnis fürs System. PHP Applikationen sind für Linux Systeme geschrieben. Ja sie laufen bestimmt auch unter Windows und IIS, aber eigentlich gehören sie auf Linuxmaschinen. Um die Möglichkeiten eines Systems wirklich ausschöpfen zu können gehört ein bestimmtes Verständnis des Systemes dazu. Bis vor einigen Monaten hätte ich nichts mit einem SSH Zugriff anfangen können, doch jetzt kann ich bereits einfache Tasks remote durchführen, Konfigurationen ändern und wenn ich im Internet irgend eine Anleitung mit einem Terminal Befehl sehe, dann bin ich nicht abgeschreckt, sondern kann etwas damit anfangen.

Fazit

Drupalentwickler gehören auf ein Unix System. Ja ja. Es läuft auch auf Windows, aber Mac Anwendungen werde ich auch nicht unter Windows entwickeln und umgekehrt werde ich sicher kein .Net Programm unter Linux schreiben. Alles was im Office Bereich ist. Nein, Open Office hat einfach nicht die Qualität wie MS Office. Der Office Bereich gehört Windows, der PHP Entwicklungsbereich gehört Linux. Und wenn man wie ich praktisch nie ein Word Dokument schreiben muss, sondern zum Entwickeln angestellt ist, dann könnte man eigentlich getrost Linux als primäres Betriebssystem laufen lassen und Windows für irgendwelche Spezialapplikationen in eine VM verbannen.

Und noch als kleines Gimick. Tomboy Notes ist mein neuestes Lieblings Tool. Es kommt ursprünglich vom Gnome Desktop gibt es aber auch als Windowsanwendung. Damit lassen sich Notizen als Wiki lokal verwalten. Super schnell und super praktisch. So ein wenig wie Microsoft Onenote, aber einfach klein und Sexy.