PHPGangsta - Der praktische PHP Blog

Google kündigt an, die Welt applaudiert: Das neue Apache-Modul mod_pagespeed soll automatisch Webseiten schneller machen, ohne Aufwand und für jede Seite, eine bis zu 50% schnellere Webseite wird versprochen. Google selbst hat natürlich auch etwas davon: Wenn jede Webseite schneller abrufbar ist, können die Suchmaschinen-Spider schneller und mehr crawlen…

Doch wenn man es selbst ausprobiert sind die Ergebnisse ernüchternd. Ich habe heute Abend das Modul installiert und aktiviert (in unter 3 Minuten), und ein paar Messergebnisse mit Firebug, PageSpeed und YSlow zusammengetragen.

Ergebnis: kein nennenswerter Geschwindigkeitsschub, teilweise sogar langsamer als vorher. Einige haben bei ersten Benchmarks das selbe Ergebnis wie ich erhalten, andere jedoch sprechen von 46% Verbesserung. Es scheint sehr davon abzuhängen wie die Seite aufgebaut ist und ob bereits Maßnahmen zur Verbesserung der Performance getroffen wurden.
Außerdem habe ich auf meiner Seite nach der Aktivierung Probleme mit dem HTML-Validator gefunden die vorher nicht da waren, durch die „Verbesserungen“ habe ich plötzlich ungültigen HTML-Code!

Hat jemand von Euch bereits Tests gemacht, was ist dabei herausgekommen?

==========================
Die Installation unter Ubuntu (32bit) ist denkbar einfach:
Weiterlesen »

In einem meiner letzten Artikel schrieb ich ja bereits über Reverse-Proxies. Der Reverse-Proxy nimmt die Verbindung vom Client (Browser) entgegen, dann kann er entweder selbst den Request bedienen (statische Dateien von der lokalen Platte oder aus dem Cache), oder er verbindet sich zu einem der Backend-Webserver, ruft dort die geforderte Datei ab, und sendet sie dem Client zurück.

Ein Problem entsteht nun auf dem Backend-Webserver: Alle Requests kommen vom Reverse-Proxy. Wenn nun in den PHP-Scripten die Client-IP-Adresse verwendet wird, steht darin die IP des Reverse-Proxies.

Betroffen ist in diesem Fall die PHP-Variable  $_SERVER[‚REMOTE_ADDR‘]  als auch das Apache-Log, denn dort taucht auch immer nur die IP des Reverse-Proxy auf.

127.0.0.1 - - [03/Oct/2009:10:45:24 +0200] "GET /phpinfo.php HTTP/1.0" 200 7800 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3"

127.0.0.1 deshalb, da ich direkt auf der Linux-Maschine sowohl den nginx als auch den Apache laufen habe.

Da gibt es natürlich Lösungen. Zuerst einmal müssen wir die Client-IP irgendwie an den Backend-Webserver übergeben. Dafür gibt es den Header „X_FORWARDED_FOR“, da wird der nginx die Client-IP reinschreiben.

Im nginx muss dann folgendes gesetzt werden:

location / {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
........

Ein phpinfo() liefert dann die korrekte Client-IP in X_FORWARDED_FOR (34 ist der Server, 33 der Client):

Nun installieren wir noch ein Apache-Modul. Dieses Modul sorgt dafür, dass in die Variable $_SERVER[‚REMOTE_ADDR‘]  der Wert aus X-FORWARDED-FOR geschreiben wird, damit wir keine PHP-Scripte anpassen müssen. Außerdem sorgt dieses Modul dafür, dass im Apache-Log dieser Wert auftaucht.

Das Module, das es für diese Aufgabe gibt, lautet „mod_rpaf“. Einfach danach googlen, downloaden und in der Apache-Konfiguration laden. Oder unter Linux:

sudo apt-get install libapache2-mod-rpaf

Noch kurz konfigurieren /etc/apache2/mods-available/rpaf.conf:

<IfModule mod_rpaf.c>
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1
</IfModule>

Das Ergebnis sieht dann so aus:

192.168.1.33 - - [03/Oct/2009:10:47:23 +0200] "GET /phpinfo.php HTTP/1.0" 200 7808 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3"

Möchte man das Modul nicht installieren, muß man überall in seinen PHP-Scripten die Variable $_SERVER[‚X_FORWARDED_FOR‘] statt $_SERVER[‚REMOTE_ADDR‘] nutzen, und das Apache-Log anpassen:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Damit hätten wir das Problem auch gelöst, überall steht nun die Client-IP zur Verfügung, die Anwendungen und Logs laufen wieder korrekt.

Den Traffic einer ganzen Seite herauszufinden ist nicht sonderlich schwer in Zeiten von awstats, webalizer und diversen anderen Apache-Log-Analyzern.

Doch ich wollte damals bei meinem eigenen Browsergame den Traffic pro eingeloggtem User messen. Idee war damals, den „Free Accounts“ 100MB pro Monat zu schenken, falls mehr benötigt wird, muss ein Premium-Account her.

Doch wie stellt man das an? Das Apache-Log hilft nicht wirklich, denn dort kann man nicht die einzelnen (eingeloggten) User unterscheiden. Ich habe damals 3 Lösungen gefunden:

• mit dem Output Buffer von PHP arbeiten, Stringlänge bestimmen und mitloggen, dann Seite an den Browser schicken
• Irgendwie die IP-Adressen des Users merken, und dann das Apache-Log durchparsen und rechnen.
• die Apache-Extension mod_log_sql

Möglichkeit 1 sieht dann ungefähr so aus:

<?php
ob_start();

// some html content here

$trafficbytes = strlen(ob_get_flush());
// insert traffic into database

?>

Habe es nie ausführlich getestet, aber ich denke es ist langsam (da das HTML erst am Ende geflushed wird anstatt zwischendurch schon Häppchen zu verschicken). Außerdem muß man sich noch um Bilder kümmern, denn die sollen ja auch mitgezählt werden. Dazu würde ich eine Rewrite-Rule empfehlen, die bei jedem Bildrequest noch schnell ein php-Script ausführt. Auch das beeinflusst natürlich die Performance des Besuchers und des Webservers.

Die zweite Möglichkeit ist nicht ganz einfach umzusetzen. Die IP-Adresse allein ist nicht sonderlich aussagekräftig, einen Benutzer damit zu verfolgen recht aufwändig. In Zeiten von Proxies (Grüße an AOL), Neueinwahl bei DSL, mehrere Benutzer hinter einem Heimrouter etc reicht das nicht aus, um darüber den Benutzer zu bestimmen, gerade wenn Bruder und Schwester gemeinsam über eine Leitung im Internet sind usw.

Die dritte Alternative ist das Apache-Modul, welches ich dann auch genutzt habe: mod_log_sql. Dieses bindet man einfach in die entsprechene Apache-Config ein, und schon wird ein zusätzliches Log erzeugt, nämlich in der Datenbank. Dies kann man entweder für alle Seiten tun, oder nur für bestimmte VirtualHosts. Welche Spalten dort gefüllt werden sollen, in welcher Reihenfolge und mit welchen Daten, konfiguriert man in der apache-Config. Hier eine Beispielkonfiguration (hier für Linux, für Windows sieht es ähnlich aus: .dll statt .so usw.):

LoadModule log_sql_module modules/mod_log_sql.so
LoadModule log_sql_mysql_module modules/mod_log_sql_mysql.so

LogSQLLoginInfo mysqli://apacheloguser:apachelogpwd@localhost/apachelogdb
LogSQLCreateTables On
LogSQLMachineID mylocalmaschine
LogSQLTransferLogFormat AbHIhMmpRSstTUuvz
LogSQLTransferLogTable ztraffic_access_log
#LogSQLNotesLogTable ztraffic_notes
LogSQLCookieLogTable ztraffic_cookies
#LogSQLHeadersInLogTable ztraffic_headers_in
#LogSQLHeadersOutLogTable ztraffic_headers_out
LogSQLWhichCookies UserID     # hier könnten noch mehr Cookies stehen

Man kann alternativ zur eigenen Cookie-Tabelle auch ein bestimmtes Cookie mit ‚c‘ und „LogSQLWhichCookie“ in die access_log schrieben lassen. Hier eine Liste der Informationen, die man speichern kann.

Damit das Modul funktioniert, muß man noch das Modul „unique“ aktivieren, entweder per

a2enmod unique_id

oder via Einkommentieren von

LoadModule unique_id_module modules/mod_unique_id.so

Apache reload. Wenn man danach eine Seite besucht, liest man folgendes im apache error log:

[Tue Sep 01 19:59:46 2009] [notice] mod_log_sql: child established database connection
[Tue Sep 01 19:59:46 2009] [error] mysql_query returned (1)
[Tue Sep 01 19:59:46 2009] [error] table does not exist, preserving query
[Tue Sep 01 19:59:46 2009] [error] table doesn't exist...creating now
[Tue Sep 01 19:59:47 2009] [error] tables successfully created - retrying query
[Tue Sep 01 19:59:47 2009] [notice] query successful after table creation

Die Tabelle wurde also erfolgreich angelegt. Das Ergebnis sieht dann so aus:

Der Inhalt der Tabelle (nur 1 Zeile):

Wäre dieser Test-Request kein 304er (Not Modified), hätten wir bei „bytes_sent“ auch eine Traffic-Angabe.

Mit Hilfe der Cookie-Tabelle können wir dann zB einmal täglich den Traffic jeden Users berechnen und in die entsprechende User-Tabelle füllen. Die Log-Tabelle sollte man dann wieder aufräumen und nicht länger benötigte Zeilen löschen.

Übrigens ist das Modul nur für Linux supported. Unter Windows kann man es zwar auch kompilieren, das ist aber mehr hohem Aufwand verbunden. Ich habe damals (2004) durch Zufall eine kompilierte Version gefunden. Die ist aber heute nicht mehr brauchbar, da sie für eine sehr alte Apache-Version kompiliert wurde.

Wenn ihr Fragen habt, fragt! Oder wenn ihr evtl. bessere Lösungen kenn, her damit! Oder was könnte man noch alles anstellen mit diesen Apache-Logs in einer Datenbank?

—————————————————-

Weitere interessante Links zum Thema:

Anleitung für Debian Etch

Die offizielle Webseite des Moduls