Open Web Analytics besser als Piwik? Leider nicht in Sachen Performance!

Statistik-Tools gibt es viele, leider fehlt uns immernoch ein richtig guter Ersatz für Google-Analytics, der auf dem eigenen Server auch nur ansatzweise so performant läuft, wie es GA in der Google-Wolke tut. Nachdem Piwik aufgrund mangelnder Performance in der Vergangenheit leider nicht überzeugen konnte bekam kürzlich OWA (Open Web Analytics) eine Chance, sich zu beweisen. Als Härtest musste eine gut besuchte Seite mit mehreren mio. PI am Tag herhalten.

OWA stellt sich auf den ersten Blick genauso dar wie Piwik, das heisst ein PHP-Frontend mit MySQL-Backend sowie die Erfassung der Statistiken durch Einbindung eines JavaScripts in die Zielseite. Kennen wir ja von Google Analytics, das System ist auch durchaus einfach zu implementieren. Optional kann man die Statistiken auch direkt via PHP erfassen, wir nehmen aber für den Test die JS-Variante. Leider funktionierte der Login im Backend mit Safari nicht, unter Firefox jedoch problemlos

Im Vergleich bietet OWA ein sehr interessantes Feauture, das Piwik vermissen lässt, nämlich das sogenannte "Event Queueing". Damit ist es möglich, die Logdaten nicht direkt in die MySQL-Datenbank, sondern in ein normales Logfile (die Queue) schreiben zu lassen. Anschließend kann man dann per Cronjob oder manuell durch einen PHP-CLI-Aufruf die Analyse dieses Logfiles starten. Das klingt auf den ersten Blick nach einer eventuellen Lösung für die Performance-Probleme, die OWA wie Piwik beim direkten Schreiben der Logs in die Datenbank hat.

Denn auch bei OWA stieg die Serverlast trotz optimiertem MySQL und einer recht potenten Serverbasis (Dual Dualcore Opteron mit 2.6 GHz, 8 GB RAM, Linux, Lighty mit Fast-CGI und xCache) die Loadavg innerhalb weniger Minuten auf über 100.0 und der Server wurde unbenutzbar. Dies ist einfach den tausenden Requests pro Minute geschuldet, die die Datenbank einfach nicht weggeschrieben bekommt. Genau dieses Verhalten stellte sich ja damals auch bei Piwik dar.

Mit der Event-Queue blieb die Last im Rahmen (Loadavg unter 2.0), das Plaintext-Logfile wird also schnell geschrieben und der Lighty bekommt die vielen PHP-Anfragen gut abgearbeitet. Wie allerdings Kollisionen beim gleichzeitigen Zugriff auf das Logfile verhindert werden, ist unklar. Im schlimmsten Fall könnte das File dann zerstört werden, schließlich passiert dies ja auch alles via PHP. Man müsste man den Code durchsehen, ob da konkret Locking benutzt wird oder wie das nun genau funktioniert. Im Test wurde das File zumindest recht problemlos geschrieben, in 10 Minuten sammelten sich so um die 250 MByte im Log an.

Diese Daten galt es nun auszuwerten, wofür man "php cli.php cmd=processEventQueue" auf der Shell bemüht. Im Hintergrund wird das aktuelle Log dabei in ein Tempfile verschoben und ein neues Logfile begonnen, so dass es während der Auswertung nicht zu Datenverlust kommt. Eine nette Logik, schließlich muss man die Auswertung regelmäßig anstoßen, idealerweise dann als Cronjob.

Wo wir auch schon beim größten Nachteil von OWA wären: Die Auswertung ist furchtbar langsam! Für die 250 MByte aus 10 Minuten Logging in die EventQueue brauchte OWA zur Analyse über 30 Minuten bei guter Datenbank-Auslastung und mäßiger Serverlast (Loadavg um 4.0). Teilweise verhing es sich offenbar auch in einer Endlosschleife, so dass man den Prozess killen musste. Und jeder weitere Durchlauf war deutlich langsamer als der vorherige, da in der MySQL-DB ja immer mehr Daten bewegt werden mussten. Dass es keinen Sinn hat, wenn die Auswertung der Daten länger dauert als der eigentliche Erfassungszeitraum war, ist wohl klar

Fazit:
Auch OWA ist für den Einsatz bei Seiten mit hohem Traffic nicht benutzbar, da hilft auf die EventQueue nicht. Der Ansatz mit dem Logfile ist dennoch gut. In der Benutzung und im Interface ähnelt es Piwik ziemlich, Piwik gefällt aber ingesamt besser und stellt sich aufgeräumter dar.

Eine Alternative für GA ist also weiterhin gesucht ...