PHPGangsta - Der praktische PHP Blog

Wie wir alle wissen kann man die größten Performanceverbesserungen auf der Browserseite erreichen. Ich habe bereits das Zusammenfassen von CSS- und Javascript-Dateien vorgestellt, ebenso wie das Zusammenfassen von Bildern in CSS-Sprites. Damit wird die Anzahl der Request schonmal reduziert. Aber es gibt natürlich noch mehr zu tun, beispielsweise die Requests noch weiter reduzieren durch gute Cache-Einstellungen, die wir an den Brower senden. Das werde ich hier vorstellen ebenso wie die Komprimierung mittels gzip/deflate der Dateien, die dann noch heruntergeladen werden müssen.

Cache-Einstellungen werden via HTTP-Header an den Browser mitgesendet. Zum Beispiel der Expires-Header, der angibt wie lange der Browser eine Datei cachen soll bevor er nach einer neuen Version fragt. Diese Cachedauer setzt man je nach Dateityp relativ hoch auf mehrere Tage.

Damit die unten stehenden Anweisungen vom Apache interpretiert werden können muss man das „Expires-Modul“ aktivieren, häufig kann man das wie folgt erledigen:

a2enmod expires

Hier die entsprechenden Apache-Einstellungen, die man entweder global im Apache einstellen kann, oder im entsprechenden vhost der Domain oder aber in der .htaccess-Datei speziell für Ordner:

<IfModule mod_expires.c>
    # turn on the module for this directory
    ExpiresActive on
    # set default
    ExpiresDefault "access plus 24 hours"

    # cache common graphics
    ExpiresByType image/jpg "access plus 1 months"
    ExpiresByType image/gif "access plus 1 months"
    ExpiresByType image/jpeg "access plus 1 months"
    ExpiresByType image/png "access plus 1 months"

    # cache CSS
    ExpiresByType text/css "access plus 1 months"

    # cache other filetypes
    ExpiresByType text/javascript "access plus 1 months"
    ExpiresByType application/javascript "access plus 1 months"
    ExpiresByType application/x-shockwave-flash "access plus 1 months"
</IfModule>

Mit dem Firefox-Addon Firebug kann man sich das Ergebnis anschauen:

Wie man im obigen Bild sehen kann wurde diese Datei auch gzip-komprimiert an den Browser gesendet. Dies macht vor allem Sinn bei textbasierten Dateien wie HTML, CSS, Javascript usw. Komprimierung bei bereits komprimierten Bildern wie jpg, png oder gif macht keinen Sinn, diese werden wir nicht komprimieren.

Dazu benötigen wir im Apache2 das „Modul Deflate„, und wir werden für bestimmte Dateitypen die Komprimierung aktivieren. Genau wie oben kann man die unten stehenden Anweisungen nach der Aktivierung des Moduls an die 3 bekannten Stellen setzen:

a2enmod deflate

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/x-shockwave-flash

    DeflateFilterNote Input input_info
    DeflateFilterNote Output output_info
    DeflateFilterNote Ratio ratio_info
    LogFormat '"%r" %s %{output_info}n/%{input_info}n (%{ratio_info}n%%)' deflate
    CustomLog /var/log/apache2/deflate_log deflate
</IfModule>

Die oberen Zeilen sollten verständlich sein, die unteren 5 Zeilen sind dazu da ein spezielles Log mit Komprimierungsinformationen anzulegen. Dieses sieht dann wie folgt aus:

"GET /wp-includes/images/smilies/icon_wink.gif HTTP/1.1" 200 -/- (-%)
"GET /wp-content/themes/journalist/images/top.gif HTTP/1.1" 200 -/- (-%)
"GET /wp-content/plugins/syntaxhighlighter/syntaxhighlighter/styles/shCore.css?ver=2.1.364b HTTP/1.1" 200 1917/7297 (26%)
"GET /wp-content/plugins/syntaxhighlighter/syntaxhighlighter/styles/shThemeDefault.css?ver=2.1.364b HTTP/1.1" 200 1095/3636 (30%)
"GET /wp-content/plugins/wp-cumulus/tagcloud.swf?r=5611069 HTTP/1.1" 200 34520/34610 (99%)
"GET /wp-content/plugins/wp-cumulus/tagcloud.swf?r=8457739 HTTP/1.1" 200 34520/34610 (99%)
"GET /wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/corners.gif HTTP/1.1" 200 -/- (-%)
"GET /wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/buttons.gif HTTP/1.1" 200 -/- (-%)
"GET /wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/horizontal.gif HTTP/1.1" 200 -/- (-%)
"GET /wp-includes/js/tinymce/themes/advanced/link.htm?ver=327-1235-syntaxhighlighter2.3.8 HTTP/1.1" 200 974/2655 (36%)
"GET /wp-includes/js/tinymce/tiny_mce_popup.js?ver=327-1235 HTTP/1.1" 200 1921/5223 (36%)
"GET /wp-includes/js/tinymce/utils/mctabs.js?ver=327-1235 HTTP/1.1" 200 751/1786 (42%)
"GET /wp-includes/js/tinymce/utils/form_utils.js?ver=327-1235 HTTP/1.1" 200 1895/5303 (35%)
"GET /wp-includes/js/tinymce/utils/validate.js?ver=327-1235 HTTP/1.1" 200 1578/4764 (33%)
"GET /wp-includes/js/tinymce/themes/advanced/js/link.js?ver=327-1235 HTTP/1.1" 200 1467/4803 (30%)
"GET /wp-includes/js/tinymce/themes/advanced/skins/wp_theme/dialog.css?ver=327-1235-syntaxhighlighter2.3.8 HTTP/1.1" 200 1722/5510 (31%)
"GET /wp-includes/js/tinymce/themes/advanced/skins/wp_theme/img/fade-butt.png HTTP/1.1" 200 -/- (-%)
"GET /wp-includes/js/tinymce/themes/advanced/skins/wp_theme/img/tabs.gif HTTP/1.1" 200 -/- (-%)

Wie man sieht sind die Bilder nicht komprimiert worden, die CSS- und Javascript-Dateien sind teilweise auf 26% komprimiert worden. Wie man auch gut sehen kann bringt die Komprimierung der swf-Datei garnichts, man kann es also wieder deaktivieren.

Bei Änderungen an der apache2.conf bzw. den vhost-Dateien sollte man natürlich daran denken den Apache neuzustarten, damit die Änderungen aktiv werden.

In diesem Zusammenhang möchte ich auch nochmal auf die beiden sehr nützlichen Firefox-Addons Google Pagespeed und YSlow aufmerksam machen. Beide geben einen sehr guten Überblick wo Probleme liegen und was man noch verbessern kann.

Heute eine kurze Linkliste, irgendwie war die Anzahl der guten Blogartikel diese Woche nicht so hoch. Oder ich hab sie nicht gelesen, falls ihr welche habt, her damit!

Sehr coole Webseite, die Tests durchführt und viele nützliche Graphen anzeigt, wie verschiedene Browser (IE7/IE8) eine Seite laden und anzeigen. Gute Ergänzung zu YSlow/Google Pagespeed etc.
http://www.webpagetest.org
ETags im Apache deaktivieren
http://www.lavluda.com/2008/10/20/website-optimization-01-disable-etag-in-apache-debianubuntu/
PHP 5.3.2 Changelog
http://www.php.net/ChangeLog-5.php#5.3.2
Chaosradio Podcast über die Geschichte, Probleme und Zukunfsaussichten von Javascript
http://chaosradio.ccc.de/cre146.html

Ab heute ist phpgangsta.de auch über https erreichbar. Wer also sicher gehen möchte dass er auch auf dem richtigen Server landet und keinen „Mann in der Mitte“ zuhören kann ab jetzt auch https://www.phpgangsta.de besuchen.

Warum hat das eigentlich nicht jeder? Gäbe es keine Nachteile wäre das wohl so, aber normalerweise kosten SSL-Zertifikate Geld, viel Geld, je nachdem wieviele Funktionen das Zertifikat erfüllen soll. Es ist zwar auch möglich, sich selbst Zertifikate zu erstellen, dann bekommt der Benutzer jedoch eine Fehlermeldung zu dem selbst signierten Zertifikat, und das möchte man eigentlich seinen Usern nicht zumuten.

Es gibt aber auch kostenlose, von einer Certified Authority (CA) signierte Zertifikate, und genau solch eins habe ich hier nun installiert. Wie man ein solches Zertifikat von StartSSL bekommt könnt ihr im Heise-Artikel „SSL für lau“ nachlesen. Es gibt natürlich auch noch weitere Anbieter, zB CaCert.

Danach haben wir also 3 Dateien:

• Ein Zertifikat für die Domain (hier phpgangsta.de.crt)
• Eine Datei mit dem privaten Key(hier phpgangsta.de.key)
• Ein sogenanntes Intermediate Zertifikat, auch Chain-Certificate oder Kettenzertifikat genannt (hier sub.class1.server.ca.pem)

Nachdem man ein solches Zertifikat erhalten hat, muss man es noch im Webserver installieren. Ich gebe hier 2 Anleitungen, einmal für den Apache2 und einmal für nginx.

Der Apache2 benötigt zuerst einmal SSL-Support, dazu sollte man das entsprechende Modul installieren:

sudo a2enmod ssl

Dann benötigen wir einen zusätzlichen VirtualHost, der die SSL-Verbindungen entgegennimmt. Darin definieren wir auch die Pfade zu den Zertifikaten:

<VirtualHost 85.214.28.26:443>
  ServerName phpgangsta.de
  ServerAlias www.phpgangsta.de php-gangsta.de www.php-gangsta.de
  ServerAdmin username@gmx.de
  DocumentRoot "/path/to/phpgangsta/wordpres/"

  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/phpgangsta.de.crt
  SSLCertificateKeyFile /etc/apache2/ssl/phpgangsta.de.key
  SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem

<hier noch viele Anweisungen zum Logging, safe-mode, open_basedir, deflate, expires usw.>
</VirtualHost>

Nach dem Ändern der Apache-Konfigration benötigen wir natürlich noch einen Restart des Dienstes:

sudo /etc/init.d/apache2 configtest
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start

Danach sollte die Domain auch verschlüsselt zur Verfügung stehen.

Im nginx geht es ähnlich einfach:

Um SSL nutzen zu können muss nginx mit dem configure-Parameter –with-http_ssl_module kompiliert sein. Dann fügt man einen weiteren VHost hinzu, ähnlich wie im Apache:

server {
        listen       443 ssl;
        server_name  www.phpgangsta.de php-gangsta.de www.php-gangsta.de;

        ssl_certificate      /etc/apache2/ssl/phpgangsta.de.crt;
        ssl_certificate_key  /etc/apache2/ssl/phpgangsta.de.key;

        ssl_session_timeout  5m;

        ssl_protocols  SSLv3;
        ssl_ciphers HIGH:!ADH:!MD5;
        ssl_prefer_server_ciphers   on;

        keepalive_timeout    70;

        location / {
             proxy_pass http://backendwebserverupstream;
        }
}

Wie man sieht ist das hier ein Reverse-Proxy-VHost, der die SSL-Verbindung terminieren soll. Auch fällt auf, dass man hier nur 2 Angaben machen muss, es fehlt das Intermediate-Certificate. Das muß man beim nginx an das Domain-Zertifikat anhängen:

cat /etc/apache2/ssl/sub.class1.server.ca.pem >> phpgangsta.de.crt

Dann noch den nginx neustarten und alles ist wunderbar:

sudo /etc/init.d/nginx configtest
sudo /etc/init.d/nginx restart

Bei der Recherche zu nginx (ich habe mal das Mail-Proxy-Modul ausprobiert, funktioniert super auf den ersten Blick!) bin ich über diese Seite bei Calomel gestossen, die ich unbedingt weiterempfehlen möchte, eine schöne umfangreiche Seite die noch einige Informationen bereithält, die das nginx-Wiki nicht bietet.

Ein Problem gab es bei WordPress allerdings noch: Wenn man die Seite über https aufgerufen hat, waren die Links darin noch http://… Das konnte ich jedoch relativ einfach durch das Addon HTTPS for WordPress lösen, dann werden die Links alle korrigiert. Hätten WordPress und die ganzen Addons diese „absoluten URLS“ nicht benutzt hätte es das Problem auch nicht gegeben.

Da ich mir natürlich wünsche dass meine Artikel auf anderen Seiten weiterverlinkt werden, vereinfache ich nun das Setzen von Bookmarks bei bekannten Diensten sowie das Retweeten mit Hilfe des WordPress-Addons SexyBookmarks. Dadurch sind nun unter jedem Artikel ein paar Symbole von Sozialen Netzwerken und Bookmark-Diensten, mit denen man mit einem Klick den Artikel verlinken kann.

Da ich nicht genau weiß welche Dienste ihr nutzt habe ich erstmal die mir bekannten Dienste dort angezeigt. Falls ihr ein Symbol vermisst (und es in der Liste der unterstützten Features ist) füge ich es natürlich gern hinzu.

Was könnte ich sonst noch tun, um euch zu animieren, meine Artikel zu verlinken? 🙂

Hier erstmal das Video, damit ihr seht worum es geht:

Dies ist das Video, das ich gerade erstellt habe, und zwar vom Zend Framework 1.10 branch. Man sieht, wo welche Programmierer mitgeholfen haben, wer häufig welche Art von Dateien bearbeitet usw. Mit mehr Zeit könnte man da noch andere coole Dinge mit anstellen, wie beispielsweise weitere Dateiendungen farbig markieren etc. etc.

Es gibt natürlich auch aussagekräftigere Tabellen und Statistik-Tools, aber ich finde das eine sehr schöne Darstellung, sollte man mal von seinem Projekt machen wenn mehrere Leute involviert sind (als Motivation).

Code_Swarm kann auf svn, git, hg und wahrscheinlich noch weiteren Repositories losgelassen werden. Wie man es installiert und laufen lässt steht hier:

http://github.com/rictic/code_swarm

ich möchte es nicht kopieren. Ich habe es bereits ohne Probleme unter Mac OS X und Ubuntu ans Laufen bekommen. Unter Ubuntu 9.10 sah das so bei mir aus:

cd
mkdir code_swarm
cd code_swarm
sudo apt-get install git-core subversion mencoder
git clone git://github.com/rictic/code_swarm.git
svn co http://framework.zend.com/svn/framework/standard/branches/release-1.10/
export PATH=$PATH:~/code_swarm/code_swarm/bin
cd release-1.10
code_swarm

Der erste Aufruf von code_swarm generiert eine Folge von Ergebnisbildern, die man auch als Film angezeigt bekommt.. Um viele Tausend png-Bilder auf der Festplatte zu generieren, die wir dann noch in einen Film umwandeln können, muss in der Projektdatei (~/code_swarm/release-1.10/.svn/.code_swarm/project.config) folgendes geändert werden:

ColorAssign3="Source Code"   <-- .php hinzufügen
TakeSnapshots=true
SnapshotLocation=frames/#####.png

Dann nochmal code_swarm im Repository-Verzeichnis aufrufen, anschliessend wird der Aufruf von mencoder daraus ein Video generieren:

cd ../code_swarm/frames/
mencoder mf://*.png -mf fps=24:type=png -ovc lavc -oac copy -o video1.avi

Bei Problemen oder weiteren Einstellungsfragen sollte man dieses HowTo gelesen haben. Hier ist noch ein Posting wo man sehr viele Einstellungsmöglichkeiten sehen kann (Die „Masse“ der Entwickler, Framegröße, Geschwindigkeiten usw)

Weitere interessante Projekte, die sich mit der visuellen Darstellung von Repositores oder Logs beschäftigen, kann man hier sehen:

http://code.google.com/p/gource/

http://code.google.com/p/logstalgia/