Administrator's Blog

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 ...

So ein Dock ist eigentlich eine wirklich gute Sache. Meine Ex-Dell Notebooks zumindest habe ich eigentlich ganz gerne im Dock betrieben, da man sich die tägliche Neu-Verkabelung von LAN, Strom, USB und VGA damit sparen konnte. Nach dem Umstieg auf ein MacBook Pro vermisst man das auch ein wenig, denn trotz Cinema-Display muss man mehrfach täglich mindestens 3 Kabel an- und abstecken (Strom, Display-Port und USB). Außerdem sieht es immer ein wenig unordentlich aus, wenn die Kabel so auf dem Tisch zu sehen sind.

Einen Workaround dafür bietet der US-Hersteller Henge Docks an. Deren Docks nehmen sowohl das kleine MacBook als auch alle Varianten des MacBook Pro hochkant (!) in einem Plastikständer auf. Ein echtes "Dock" ist es eigentlich nicht wirklich, da es keinerlei Anschlüsse nach außen stellt. Wie auch, dem MacBook fehlen ja echte Dock-Anschlüsse auf der Unterseite, wie sie z.B. Dell-Notebooks haben.

Also muss man seine normalen Kabel im Dock befestigen. Dies geschieht mittels Inbusschrauben. Je nachdem, was man für Anschlüsse nutzen möchte, gilt es also diverse Kabel im Dock zu befestigen. In meinem Fall zur Nutzung an einem Apple Cinema-Display sind dies also USB, Strom und Display-Port. Dies ist auch schon ein recht großer Nachteil an der Sache, denn will man ein anderes MacBook an diesem Display betreiben, muss man natürlich die ganzen Schrauben lösen.

Ansonsten passt das MacBook Pro ziemlich gut in das Dock und lässt sich leicht herausnehmen bzw. reinstecken. An die Optik gewöhnt man sich, dennoch ist die Lösung im Hochkant-Modus ein wenig "strange". Das SuperDrive funktioniert in der Stellung offenbar problemlos inkl. Auswurf nach oben, intensive Tests wurden allerdings nicht durchgeführt.


Probleme gibt es allerdings auch, so funktionierte beim Test mit einem "Display-Port zu DVI Adapter" die Erkennung des Monitors teils nur sporadisch. Der Monitor blieb teilweise einfach aus. Abhilfe schaffte dann nur die etwas nervige Prozedur, das MacBook herauszunehmen, aufzuklappen, den Monitor anzustecken, das 2. Display zu konfigurieren und dann wieder in das Dock zu stecken. Dass das keinen Spaß macht, kann man sich ja denken. Mit dem Cinema-Display gibt es allerdings keinerlei Probleme, das wird stets erkannt.

Ein weiteres Problem gab es mit Bluetooth, konkret brach die Verbindung zur MagicMouse oft ab. Außerhalb des Docks gab es diese Probleme nicht. So richtig nachvollziehbar ist das Problem technisch allerdings nicht, da laut ifixit.com der BT-Empfänger in der rechten oberen Ecke sitzt. Und diese Ecke steht ja oben aus dem Dock heraus.

Insgesamt aber ein ganz nettes Dock für das MacBook [Pro] (und wohl auch das eizig derzeit verfügbare Modell) mit einigen Schwächen bzw. Designfehlern, die aber natürlich auch daran liegen, dass Apple die Nutzung im Dock nicht wirklich vorsieht. Samt Zoll und Versand nach Deutschland ist unser Test-Dock für rund 90 EUR bei Henge Docks aus den USA zu haben.