Aufbauend auf meinem Artikel zum AjaxAction View Helper möchte ich nun mein CacheAction plugin für das Zend Framework vorstellen. Es wird einfach als FrontController Plugin registriert und cacht die Responses von Controlleraktionen.

Soweit noch keine Kunst. Seine ware Stärke spielt das Plugin erst in Verbindung mit dem AjaxAction View Helper aus. Die zwei sind zusammen das dynamische Duo :-)

Das Prinzip ist einfach:
Liegen die Ergebnisse von einer Controlleraktion bereits im Cache vor, so wir der Inhalt ohne Umwege, direkt in das HTML der Hauptseite eingebaut und ausgeliefert. Ist das Ergebnis noch nicht im Cache, wir die Seite unvollständig, aber schnell ausgeliefert und der fehlende Inhalt kommt per AJAX hinterher. (more…)

Bei größeren Webapplikationen kann es immer mal wieder vorkommen, das Inhalte oder ein Teilbereiche einer Webseite nicht spontan verfügbar sind. Ursachen dafür sind oft kalte Caches von Models oder die Latenzen die durch die Kommunikation mit extenen Webservices bedingt sind. Ich war es irgendwann Leid diese Wartezeiten zu einem Problem des Users machen zu müssen und habe einen kleinen View Helper entwickelt, der langlaufende Prozesse loskoppelt und das Ergebnis per AJAX nachliefert.

Im Prinzip wird die Webseite unvollständig an den User übermittelt und dann in seinem Webbrowser fertig gerendert. (more…)

In meinem Web Rocker Showdown zum Thema Zend Framework vs. Ruby On Rails habe ich als PHP-Stack und Applikationsserver den Zend Server Community Edition verwendet. Während des Tests war mir aufgefallen, das der Zend Server CE die Harware nicht voll ausnutzt. Alle 4 CPUs waren nur zu 60% belegt. Dieses Phänomen möchte ich in diesem Artikel genauer untersuchen indem ich den Zend Server CE mit der kommerziellen Version und einem PHP 5.3 aus dem DotDeb-Repository vergleiche. Die Testhardware, das Betriebssystem und die PHP-Applikation sind identisch mit dem vorherigen Showdown. (more…)

User Acceptance Tests (UAT) oder auf Deutsch “Akzeptanztests” sind eine wichtige Komponente in der Testgetriebenen Entwicklung. Bisher kannte ich die üblichen Verdächtigen, also Selenium. Man kann damit komfortabel einen Klickpfad definieren, PHP-Code exportieren und daraus einen Test für PHPUnit erzeugen. Leider benötigen diese Tests immer einen laufenden Seleniumdienst, einen Browser und diesen ganzen Kram. Ich bin eher ein Fan von Testmethoden die headless funktionieren, direkt auf einer Shell. Bei meinem Blick über den Tellerrand in Richtung Ruby On Rails bin ich auf Cucumber aufmerksam geworden. Cucumber ist ein tolles Test-Framework für Behaviour Driven Development, das mit menschenlesbaren Tests im Klartext arbeitet. Zusammen mit Webrat, einem Toolkit um Webbrowser fernzusteuern oder mit Mechanize komplett headless zu arbeiten, kann man Webapplikationen hervorragend testen.

Am Beispiel der Google-Suche werde ich zeigen, wie einfach man Tests mit Cucumber anlegen kann und das Testen damit wirklich Spaß macht :-) (more…)

rps_vs_c

Heute geht es um ein Frage, die mich schon lange beschäftigt: Was ist schneller? Zend Framework MVC oder Ruby on Rails? Und wie skalieren die unterschiedlichen Architekturen bei zunehmenden, parallelen Zugriffen? Wie effizient wird meine Hardware genutzt? Die Antworten auf diese Fragen habe ich natürlich für Euch in einem Web-Rocker Showdown empirisch ermittelt :-)

Mein Versuchsaufbau sieht wie folgt aus:

Hardware:
Dell PowerEdge 860
Intel XEON QuadCore mit 2,13 Ghz
4 Gb Arbeitsspeicher
SAS300 Hardware RAID0
2x 73Gb 10k SAS HDDs

Software:

Debian 5.0.7 x86_64
Apache Bench
Htop (more…)

Nie wieder Rechteprobleme im Dateisystem! Klingt unglaublich? Ist es aber nicht, zumindest nicht für Entwicklungsumgebungen.

Die meisten Entwicklungsumgebungen sehen oft wie folgt aus:

  • – Linuxserver
  • – Samba-Freigabe vom Rootverzeichnis der Webservers oder einzelner Projekt-VHosts
  • – Apache Webserver mit VHosts für jedes Projekt
  • – Die Entwickler mounten die Samba-Freigaben und arbeiten auf ihnen

Nun kommen wir zum eigentlichen Problem: Der Apache erzeugt Dateien als Benutzer www-data in Gruppe www-data, die Entwickler als Benutzer entwicklerx in Gruppe users.
Natürlich kann man die Verzeichnisrechte durch Stickybits, PHP-Umasks usw. in den Griff bekommen. Das ist aber recht kompliziert und funktioniert auch nicht überall wirklich zuverlässig.

Mit dem Modul apache2-itk-mpm läuft der Webserver als Benutzer root und ist dadurch in der Lage für jeden VHost einen Worker-Thread mit der Identität eines normalen Benutzer zu starten. Für einen Livebetrieb ist das natürlich ein Sicherheitsrisiko, der Livebetrieb ist aber auch selten das Problem. Die Entwicklungsarbeit kostet und jeden Tag Nerven.

Und so funktioniert es am Beispiel eines Debianartigen Systems: (more…)

Kennen wir das nicht alle? Ein neues Feature muss entwickelt werden und es darf auf keinen Fall in das nächste Release? Subversion hat für diese Aufgabe mächtige Funktionen: copy, merge und merge –reintegrate. Damit das reintegrate funktioniert muss die Repository und Client Version mindestens 1.5 sein, vorher gab es noch kein Merge Tracking.

Mit svn copy können wir einen privaten Branch des Trunks erstellen. Änderungen die wir dort einchecken betreffen nur unseren Branch, nicht den Trunk.

Mit svn merge können wir aktuelle Erweiterungen die im Trunk gemacht wurden in unseren Branch synchronisieren. Mergen sollte man so oft es geht, mindestens ein Mal am Tag. Nur wenn der Branch und der Trunk so synchron wie möglich sind, wird das zurückführen des Branches in den Trunk problemlos funktionieren. Wer das regelmäßige Mergen vergisst, der schaufelt sich langsam aber sicher sein eigenes Grab.

Mit svn merge –reintegrate wird dann schlussendlich unser privater Branch wieder in den Trunk eingegliedert.

So könnte die Arbeit mit einem Branch aussehen: (more…)