B. Boerngen-Schmidt

Die ganze Zeit habe ich PHP als FastCGI über mod_fcgid laufen gehabt und war eigentlich auch ganz zufrieden. Auf dem jetzigem Server war ich über die Performance aber doch sehr enttäuscht. So wurden durchschnittlich nur 0,49 Requests/Sek. verarbeitet, laut ab -n1000, was meiner Ansicht nach doch etwas sehr wenig ist. Darum habe ich mich entschlossen kurzer Hand wieder mod_php einzusetzen und siehe da, die Requests pro Sekunde sprangen auf 1,89 Requests/Sek.

Apache ITK

Da mir aber auch an Sicherheit gelegen ist soll PHP aber nicht als www_data respektive apache laufen. Außerdem fand ich es bei PHP als FastCGI doch sehr angenehm, dass man sich seine eigene php.ini anlegen konnte. Mit dem ITK Patch für Apache ist es möglich einem vHost einen Benutzer und eine Gruppe zu zuweisen unter welchem Sie laufen sollen, also wird nicht erst der PHP Prozess sondern direkt der vHost, respektive der Apache Prozess, unter diesem Benutzer ausgeführt. Einen schönen einführenden Artikel zu Apache ITK hat Stuart Herbert in seinem Blog geschrieben.

AssignUserID user group

Dies ist die einzige Ergänzung die im vHost gemacht werden muss um ihn einem speziellen Benutzer zu zuordnen.

PHP mit eigener php.ini

Wenn Apache ITK läuft brauch man nur noch mod_php zu aktivieren und PHP läuft nun auch unter dem angegebenem Benutzer, dennoch hat mod_php die Eigenschaft eine gemeinsame php.ini zu verwenden. Aber auch hierfür gibt es Abhilfe! Bei askapache.com gibt es einen netten Artikel über Custom php.ini tips and tricks über den ich eine Lösung für das Problem der php.ini gefunden habe. Im vHost Container muss einfach folgende Direktive gesetzt werden:

<span style="text-decoration: line-through;">PHPIniDir /path/to/php_ini/</span>

Nun wird die php.ini welche sich in diesem Verzeichnis befindet geladen.

Leider muss ich das oben geschriebene revidieren, da das Setting PHPIniDir nicht pro vHost sondern global gilt. Es scheint bis jetzt so, als wäre es nicht möglich mit mod_php für jeden vHost eine eigene php.ini festzulegen.

Fazit

Durch Apache ITK und einigen Einstellungen ist es möglich ein wesentlich performanteres PHP zu bekommen, dass zudem Vergleich zur FastCGI Variante auch noch mehr Features besitzt und nicht unter dem generellen Benutzers des Apache Webservers läuft.

Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Agavi's Filter sind wie eine Zwiebel

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilter registriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. Eine Action generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit dem FormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden in app/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

ENGLISH TRANSLATION WILL FOLLOW!

Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilterregistriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. EineAction generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit demFormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden inapp/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

Seit ein paar Tagen habe ich nun auch bei Hetzner einen Rootserver gemietet und muss sagen, dass ich im Vergleich zu Server4You sehr zufrieden bin. Die Hardware und Preis stimmen, das einziges kleine Manko ist die doch relativ hohe Einrichungsgebühr von 149EUR.

Der Server lässt sich sehr komfortabel über den Robot steuern, also Neustarten, Rescue etc. Bei dem Rescuesystem gibt es allerdings einige Kleinigkeiten die mich stören. Diese sind, dass das Passwort nur sehr kurze Zeit angezeigt wird, der Rescuemodus wird nach 5 Minuten wieder beendet somit ist kein Reboot im Rescue möglich. Ehrlich gesagt kann ich den letzen Punkt verstehen, da man eigentlich nur einmal ins Rescue bootet und dann hoffentlich nie wieder.

Fazit: Bis jetzt scheint Hetzner ein sehr fähiger und guter Provider zu sein, mal sehen wie sich dies in Zukunft verhalten wird.

Seit dem heutigen Tag habe ich ein zweisprachiges Blog in dem ich versuchen werde die meisten Artikel sowohl auf Deutsch als auch auf Englisch zu schreiben.

Es hat wirklich lange gedauert bis ich dieses Vorhaben endlich umsetzen konnte, da mir dazu immer das entsprechende Plugin oder die Unterstützung durch WordPress gefehlt hat. Durch Zufall bin ich aber auf das Plugin qTranslate aufmerksam geworden, welches genau dieses Feature zur Verfügung stellt.

Auf dann, ab in eine zwei sprachig Zukuft.Since today I own a blog which from now on will serve most articles in two langauges, german and english.

It took me a while to complete this undertaking since I was not able to find a suitable Plugin nor did WordPress on its own support this feature , but I succeeded at last. Per incedent I found the Plugin qTranslate, which exactly supports multi language.

Towards a future of bilingual post.

SysCP ist ein prima Tool um einfach und schnell eine Webhostingumgebung zu managen. Besonders seine “keep it simple” Idee macht es zu dem was es ist. Leider sieht es unter der Haube etwas anders aus. Dort ist es seit einiger Zeit so, dass der Code ein Stadium erreicht hat, in dem er alles andere als simpel zu verwalten ist.

Darum habe ich mich entschlossen eine Fork von SysCP zu starten, der vorerst unter dem Namen SysCP-ng laufen wird. Ziel der Version 1.0 ist es die derzeitige Funktionalität von SysCP (1.4.2) nachzubauen.

Mal sehen was drauß wird.

Das gute Trac lief bei mir zuerst über mod_python und ich war auch ganz zufrieden damit, da ich so ziemlich der einzige Nutzer des Tracs war. Ein paar kleine Tests mit dem ab (Apache Benchmark) Tool brachten jedoch hervor, das in 30s nur knapp 100 Requests verarbeitet werden konnten. Auf der Suche nach Verbesserungen habe ich gelesen, dass mod_wsgi eine Performancesteigerung bringen soll. Erste Tests haben das auch erwiesen, denn nun schafft mein Apache knapp 200 Requests in 30s.

Auch der Wechsel von SQLite zu Postgres hat meiner Meinung nach eine spürbare Verbesserung ergeben.

Zuletzt sollte man auch noch bedenken, dass Trac doch einige Statische Inhalte serviert, wie das Logo und die CSS Files. Am günstigsten ist es hier diese Dateien aus dem lokalen Webbrowsercache zu laden. Alle statischen Inhalte liegen bei Trac im Verzeichnis chrome.

<LocationMatch /chrome>
	SetHandler None
	Order allow,deny
	Allow from all
	ExpiresDefault "now plus 12 hours"
</LocationMatch>

Um nach einem Domainumzug möglichst schnell wieder auf seine eigene Domain zugreifen zu können, benötigt man die richtige IP, die ja im Internet per DNS ermittelt wird. Damit aber nicht immer ein DNS Server nach der IP gefragt werden muss legen die Betriebssysteme lokal einen Cache an. Um bei Mac OS X den DNS Cache durchzuspülen, damit die neusten DNS Einstellungen vom Server geladen werden gibt man in Terminal.app eines der beiden Kommandos ein.

OS X <= 10.5.1
lookupd -flushcache
OS X >= 10.5.2
dscacheutil -flushcache

Tadaa Cache geflushed. Sollte trotzdem immer noch die Auflösung nicht richtig klappen, nicht vergessen dass Router auch einen DNS Cache haben

Wenn man den FormPopulationFilter (kurz FPF) des Agavi Frameworks benutzt, gibt es einige Sachen auf die man achten sollte.

Keine HTML Special Charaters verwenden

Warum nicht? Nun ja, ich habe mein Output auf XHTML & UTF-8 eingestellt, so dass ich mit dem FPF meine Formulare dynamische ausfüllen kann. Nun ist das Problem, wenn man z.B. eine Navigation erstellt, dass man Sonderzeichen wie “>>” oder “<<” benutzen möchte für Vor und Zurück. Das Problem welches hierbei auftritt ist, dass der FPF denkt, dies seien Open- bzw. Endtags was ihn letztendlich aus der Bahn wirft und uns einer Exception beschert. Aber nicht nur diese Zeichen auch an “&rarr;” verschluckt sich der FPF.

Deswegen ist es am besten, wenn man Sonderzeichen benutzen möchte, den numerischen Code dieser zu verwenden. Eine gut strukturierte Übersicht findet der interessierte Leser unter http://webdesign.about.com/library/bl_htmlcodes.htm

So nun habe ich auch ein Blog und schöre mir hiermit hochheilig, dass ich es nur zum guten Verwenden werde. Nur meine Hauptfrage besteht immer noch darin: “Was mache ich jetzt mit meinem neue Blog und wie funktioniert es?”
Am besten beantwortet man sich diese Fragen, in dem man Anfängt einfach einmal auszuprobieren.

Das Adminpanel

Unübersichtlich. Das war mein erster Eindruck. Das Problem ist einfach, dass es anders ist. Aber solangsam kommt doch der tiefere Gedanken heraus und es wird immer leichter zu navigieren.

Plugins

Anscheinend gibt es eine unendliche Zahl von Plugins für WordPress. Schier gigantisch die ganze Sache. Was ich unbedingt noch brauche ist eine Erweiterung für ein Linkverzeichnis. Denn man findet so oft tolle Seiten im Netz aber sitzt nicht an seinem Rechner um sie zu bookmarken …

Themes, oder das Bild der Seite

Lustig ist eigentlich, dass ich schon genau wusste welches Theme ich verwenden wollte bevor ich WordPress überhaupt installiert hatte. Gefunden hatte ich das Theme seiner Zeit über die Themeseite von drupal. Das Theme was ich jetzt benutze stammt von nDesign (Link habe ich leider nicht zur Hand … siehe oben warum) und ist eines der schönsten was ich bis jetzt gesehen habe. Gerne würde ich mir ein komplett eigenes Design zulegen, die Ideen dafür habe ich auch, aber leider harpert es an der Umsetzung. Photoshop ist halt nicht mein Fachgebiet!

So das wars auch erstmal bis dem nächst!