B. Boerngen-Schmidt

Um noch mehr Potenzial aus meinem Apache zu kitzel habe ich mich etwas mit mod_mem_cache beschäftigt und muss sagen das Ergebnis gefällt mir.

Besonders auffällig waren die Ergebnisse bei meiner Website von SysCP-ng wo sich die Requests pro Sekunde verdoppelten von 20 auf 40. Selbst bei der von mir gehosteten Seite von Propel konnte ich einen Performanzzuwachs verzeichnen, obwohl dieser eher gering ausfiel mit einer Steigerung von 28 auf 31 Requests pro Sekunde. Den niedrigen Zuwachs kann man aber durch die größere Datenbank des Propel Tracs erklären.

Getestet wurde mit Apache Benchmark (ab) mit folgendem Kommando lokal auf dem Webserver.

ab -n 300 -c 5 http://URL/

Die Konfiguration der vHosts wurde wie folgt erweitert

<IfModule mod_mem_cache.c>
	CacheEnable mem /
	MCacheSize 32768
	MCacheMaxObjectCount 100
	MCacheMinObjectSize 1
	MCacheMaxObjectSize 4096
</IfModule>

Zwar ist die Cachegröße mit 32MB nicht sehr hoch angesetzt, aber im vergleich zu 4MB respektive 8MB war hier noch ein kleiner Preformanzzuwachs zu verzeichnen. Ob es Sinnvoll ist die Cachegröße zu erhöhen werden weitere Tests zeigen müssen. Als Literatur kann ich getrost die Seite von mod_cache empfehlen.

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.

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 sich das lokale Workspace von Eclipse im Webbrowser ansehen zu können, muss man unter MacOSX nur eine Datei in /etc/apache2/other/ hinzufügen dir folgenden Inhalt hat.

Alias /workspace /Users/workspace
<Directory /Users/workspace>
	Options Indexes MultiViews
	AllowOverride None
	Order allow,deny
	Allow from all
</Directory>

Danach muss nur noch der Apache neugestartet werden mittels

sudo apachectl restart

und schon kann man sein Workspace unter http://localhost/workspace begutachten.