Matomo langsam? Performance optimieren bei Tracking, Datenbank und Archivierung

Mit ein paar hundert Besuchen am Tag läuft Matomo laut eigener Dokumentation ohne besondere Anpassungen. Wächst der Traffic, wird es irgendwann zäh: Berichte laden ewig, die Archivierung läuft bis in die nächste Stunde hinein, und bei Traffic-Spitzen antwortet der Tracking-Endpoint nur noch langsam.

Die Stellschrauben, die Matomo selbst dokumentiert, verteilen sich auf vier Bereiche: den Tracking-Endpoint, die Datenbank, die Archivierung sowie Berichte und Oberfläche. Dieser Artikel geht sie der Reihe nach durch. Vorweg die wichtigste Regel: erst messen, dann tunen. Jede Einstellung hat einen Preis, ob Arbeitsspeicher, Datensicherheit oder Aktualität der Berichte.

Erst messen: Wo hakt es wirklich?#

Sammeln Sie Ausgangswerte, bevor Sie etwas ändern. Nur so sehen Sie, ob eine Änderung wirkt. Matomo bringt dafür eigene Werkzeuge mit:

• Systemprüfung: Unter Administration > Diagnose > Systemprüfung meldet Matomo Probleme mit PHP, Datenbank und Dateisystem. Dort steht auch, wann die Archivierung zuletzt erfolgreich durchlief; liegt das mehr als einen Tag zurück, gibt es eine Warnung. Auf der Kommandozeile liefert ./console diagnostics:run dieselbe Prüfung.
• Archivierungs-Diagnose: Seit Matomo 5.1 gibt es eigene Konsolenbefehle, etwa diagnostics:archiving-status, diagnostics:archiving-config (Einstellungen, die die Archivierung bremsen können) und diagnostics:archiving-instance-statistics (Datenmengen, die sie beeinflussen).
• Archivierungs-Log: Die Ausgabe von core:archive nennt für jede Website die Laufzeit. Über einige Tage gesammelt, zeigt sie, welche Websites und Segmente die meiste Zeit kosten.
• Datenbanknutzung: Das mitgelieferte Plugin DBStats (unter Plugins aktivieren) zeigt, wie viel Platz Rohdaten und Berichte belegen, aufgeschlüsselt nach Tabelle und Plugin.
• Slow Query Log: MySQL protokolliert auf Wunsch alle Abfragen, die länger als long_query_time Sekunden dauern. Der Standard von 10 Sekunden ist für eine Analyse meist zu grob. mysqldumpslow (bei MariaDB mariadb-dumpslow) fasst das Log zusammen.
• PHP-FPM-Statusseite: Steht bei „max children reached“ ein Wert über 0 oder wächst die „listen queue“, warten Anfragen auf einen freien PHP-Prozess.

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;

Bei MariaDB heißen die Variablen ab Version 10.11 log_slow_query und log_slow_query_time. Schalten Sie das Log nach der Analyse wieder ab oder behalten Sie seine Größe im Blick.

PHP: Version, OPcache und PHP-FPM#

Jede Tracking-Anfrage, jeder Berichtsabruf und jeder Archivierungslauf geht durch PHP. Hier lohnt sich der erste Blick:

• Aktuelle PHP-Version: Matomo empfiehlt die jeweils neueste PHP-8-Version, weil sie speichereffizienter und schneller ist als ältere. Matomo 6 setzt ohnehin PHP 8.1 voraus, siehe unsere Checkliste zum Upgrade auf Matomo 6.
• OPcache: Er hält bereits übersetzten PHP-Code im gemeinsamen Speicher, statt die Skripte bei jeder Anfrage neu zu laden und zu parsen. Prüfen Sie in phpinfo(), ob er aktiv ist. Matomo setzt den OPcache selbst zurück, wenn es seine Caches leert.
• PHP-FPM: pm.max_children begrenzt, wie viele Anfragen gleichzeitig bearbeitet werden. Zu niedrig, und Tracking-Anfragen stauen sich bei Spitzen; zu hoch, und der Arbeitsspeicher reicht nicht. Richten Sie den Wert am Speicherbedarf der Prozesse und an der Statusseite aus.
• Speicher für die Archivierung: Für memory_limit nennt Matomo 512 MB oder 2 GB für kleinere Instanzen, 8 GB seien bei mittleren bis großen Instanzen üblich. Dem Cronjob lässt sich der Wert direkt mitgeben: core:archive --php-cli-options="-d memory_limit=8G".
• Dateisystem und Webserver: Matomo rät von Netzwerk-Dateisystemen wie NFS ab und empfiehlt schlanke Webserver wie Nginx.

Tracking-Endpoint: Spitzen abfangen#

Normalerweise schreibt jede Tracking-Anfrage direkt in die Datenbank. Kommen mehr Anfragen, als Server und Datenbank gleichzeitig verarbeiten können, etwa nach einem Newsletter-Versand, wird der Endpoint zum Engpass.

Queued Tracking ist Matomos eigene Antwort darauf. Das kostenlose Plugin schreibt Tracking-Anfragen zunächst in eine Warteschlange, empfohlen in Redis, alternativ in MySQL. Das geht viel schneller als der direkte Schreibvorgang; abgearbeitet wird die Warteschlange gebündelt, nach einer Spitze eben etwas später. Matomo empfiehlt das Plugin für Instanzen mit hohem Traffic ausdrücklich.

• Standardmäßig arbeitet Matomo die Warteschlange während normaler Tracking-Anfragen ab, nachdem die Antwort an den Browser gegangen ist. Alternativ schalten Sie „Verarbeitung während der Aufzeichnungsanfrage“ in den Plugin-Einstellungen ab und starten ./console queuedtracking:process jede Minute per Cron.
• Mehr Worker („Anzahl der Warteschlangenarbeiter“) leeren die Warteschlange schneller. Matomo rät, die Zahl schrittweise zu erhöhen.
• ./console queuedtracking:monitor zeigt den Zustand der Warteschlange.
• Der Preis: Unter Last erscheinen Besuche verzögert in den Echtzeit-Berichten.

Zwei weitere Punkte betreffen jede einzelne Anfrage:

• Provider-Plugin: Es ermittelt den Internetanbieter per Reverse-DNS-Abfrage, was laut Matomo Zeit kostet. Seit Matomo 2.15 ist es bei neuen Installationen deaktiviert; wenn es bei Ihnen läuft, schalten Sie es ab oder nutzen Sie eine ISP-Datenbank.
• Geolokalisierung: Matomo empfiehlt eine Datenbank von DB-IP oder MaxMind. Für Instanzen mit hohem Traffic rät Matomo zusätzlich zur PHP-Erweiterung maxminddb, die die Abfragen des GeoIP2-Providers stark beschleunigt.

Bot- und Spam-Traffic, der gar nicht erst gespeichert wird, muss später auch nicht archiviert werden. Passende Werkzeuge dafür finden Sie unter unseren Plugins für Matomo.

Datenbank: Speicher, eigener Server, schlanke Daten#

Matomo schreibt selbst, dass die Performance stark an der Datenbank hängt: Alle Daten werden per MySQL-Abfragen gespeichert und zusammengefasst.

Eigener Datenbankserver: Ab etwa einer Million erfasster Aktionen im Monat empfiehlt Matomo mindestens zwei Server, einen für die Datenbank und einen für Tracking, Oberfläche, API und Archivierung. Die Systemanforderungen enthalten Größenempfehlungen für CPU, RAM und SSD-Speicher je Traffic-Stufe. Als grobe Schätzung nennt Matomo etwa 1 GB Datenbank je 5 Millionen Seitenaufrufe.

InnoDB-Einstellungen:

• innodb_buffer_pool_size: Matomo empfiehlt mindestens 80 Prozent des Arbeitsspeichers, der MySQL zur Verfügung steht. Das MySQL-Handbuch nennt für dedizierte Server ebenfalls bis zu 80 Prozent.
• innodb_flush_log_at_trx_commit = 2 erhöht laut Matomo den Durchsatz beim Tracking deutlich. Der Preis: Bei einem Absturz kann laut MySQL-Handbuch bis zu eine Sekunde an Transaktionen verloren gehen. Entscheiden Sie das bewusst.
• tmpdir auf ein RAM-Dateisystem wie tmpfs legen, damit temporäre Daten nicht auf der Platte landen.
• Für weitere Werte empfiehlt Matomo Werkzeuge wie MySQLTuner.

Lesedatenbank: Mit einer Replikation kann Matomo Archivierungs- und Live-Abfragen auf die Log-Tabellen an einen Leseserver schicken (Abschnitt [database_reader] in der config.ini.php). Voraussetzung laut Matomo ist eine minimale Replikationsverzögerung, sonst drohen veraltete Berichte.

Daten schlank halten:

• Wenige eindeutige URLs: Matomo nennt das ausdrücklich als wichtigen Faktor. Gängige Session-Parameter schließt Matomo automatisch aus; weitere Parameter, die URLs unnötig eindeutig machen, tragen Sie in die globale Liste oder je Website unter „Ausgeschlossene Parameter“ ein. Das wirkt nur für neue Daten.
• Alte Rohdaten löschen: Unter Administration > Privatsphäre > Daten anonymisieren („Lösche regelmäßig alte Daten aus der Datenbank“). Das spart laut Matomo viel Platz und macht Matomo etwas schneller. Die Berichte bleiben, aber für gelöschte Zeiträume fehlen danach Besucher-Log und eindeutige Besucher in Wochen und Monaten, und Berichte lassen sich nicht mehr neu berechnen. Vorher müssen alle Tagesberichte archiviert sein.
• Alte Berichte löschen: Geht ebenfalls; Matomo empfiehlt, Monats- und Jahresberichte zu behalten.

Wie lange Rohdaten aufbewahrt werden, ist auch eine Datenschutzfrage. Legen Sie die Frist mit Ihrem Datenschutzbeauftragten fest, nicht allein nach dem Speicherplatz.

Archivierung: Cronjob statt Browser#

Ab Werk berechnet Matomo Berichte, wenn jemand sie aufruft. Für Websites mit mehr als ein paar hundert Besuchen am Tag empfiehlt Matomo einen Cronjob, der stündlich archiviert:

MAILTO="admin@example.org"
5 * * * * www-data /usr/bin/php /path/to/matomo/console core:archive --matomo-domain=https://matomo.example.org > /home/example/matomo-archive.log

Danach schalten Sie die Archivierung aus dem Browser ab: unter Administration > System > Allgemeine Einstellungen „Berichte archivieren, wenn diese im Browser angezeigt werden“ auf Nein und „Archiviere Berichte mindestens alle X Sekunden“ (gemeint ist höchstens) auf 3600. Weil Segmente sonst weiterhin aus dem Browser archiviert werden, gehört zusätzlich in die config.ini.php:

[General]
browser_archiving_disabled_enforce = 1

Läuft die Archivierung eine Stunde oder länger, empfiehlt Matomo, den Cronjob seltener zu starten, etwa alle zwei oder sechs Stunden. Wenn die Archivierung hängt, abbricht oder Berichte leer bleiben, hilft unser Artikel zu Problemen bei der Matomo-Archivierung.

Berichte und Oberfläche#

Segmente vorab verarbeiten: Segmente werden standardmäßig in Echtzeit berechnet, also beim Abruf. Bei viel Traffic empfiehlt Matomo die Option „Segmentierte Berichte werden im Voraus verarbeitet“, die Superuser im Segment-Editor wählen. Mit enable_create_realtime_segments = 0 werden alle neu angelegten Segmente vorab verarbeitet. Damit ein neues Segment nicht die gesamte Historie nachrechnet, begrenzt process_new_segments_from den Startzeitpunkt:

[General]
enable_create_realtime_segments = 0
process_new_segments_from = "segment_creation_time"

Zeilenlimits: Matomo archiviert je Bericht nur eine begrenzte Zahl von Zeilen, der Rest landet in „Andere“; ab Werk sind es zum Beispiel 500 Seiten und 1.000 verweisende Websites. Wer die Grenzen über die Einstellungen datatable_archiving_maximum_rows_* anhebt, bekommt detailliertere Berichte, aber laut Matomo auch längere Archivierung, mehr Speicherbedarf und größere Archive. Heben Sie Limits deshalb nur für die Berichte an, die Sie wirklich brauchen. Für Seitenberichte bringt Matomo 6 ein neues Verfahren mit eigener Grenze mit (datatable_archiving_maximum_rows_actions_flat).

Redis als Cache: Ab Werk legt Matomo seine Caches im lokalen Dateisystem ab. Läuft Matomo auf mehreren Servern, empfiehlt Matomo einen gemeinsamen Redis-Cache, damit Caches auf allen Servern zugleich ungültig werden:

[Cache]
backend = chained

[ChainedCache]
backends[] = array
backends[] = redis

[RedisCache]
host = "127.0.0.1"
port = 6379
database = 14

Nutzt auch Queued Tracking Redis, braucht der Cache eine andere Datenbank, sonst können wartende Tracking-Anfragen verloren gehen. Matomo rät sogar zu getrennten Redis-Instanzen.

Brechen Berichte oder Dashboards trotz allem mit einem Fehler ab, lesen Sie unseren Artikel zu Timeouts und 504-Fehlern in Matomo.

Checkliste#

1. Ausgangswerte messen: Systemprüfung, Archivierungsdauer, Slow Query Log, PHP-FPM-Status.
2. PHP: aktuelle PHP-8-Version, OPcache aktiv, PHP-FPM-Pool passend zum Arbeitsspeicher.
3. Archivierung per Cronjob, Browser-Archivierung aus, browser_archiving_disabled_enforce = 1.
4. Segmente vorab verarbeiten, Startzeitpunkt für neue Segmente begrenzen.
5. Datenbank: Buffer Pool groß genug, ab etwa einer Million Aktionen im Monat ein eigener Server.
6. Datenmenge: unnötige URL-Parameter ausschließen, Löschfristen mit dem Datenschutzbeauftragten festlegen.
7. Traffic-Spitzen mit Queued Tracking abfangen.
8. Nach jeder Änderung erneut messen und nur behalten, was nachweislich hilft.

Performance-Tuning ist keine einmalige Aufgabe: Mit dem Traffic wachsen Datenbank, Archive und Segmente weiter. Wenn Sie das nicht selbst übernehmen möchten: In unserem Matomo-Hosting gehören Monitoring, Updates, Backups und Performance-Tuning dazu, und die Archivierung stimmen wir auf Ihren Traffic ab.