Performance & analysis
Matomo stays fast even with heavy traffic when topology, database, PHP and archiving fit together. I find the bottlenecks, plan the right infrastructure and scale vertically or horizontally. Then I help your team turn the data into solid analysis.
How I work
- 01Measure archiving, run times and load
- 02Plan the topology, scale vertically or horizontally
- 03Tune database and PHP
- 04Slim down segments, reports and analyses
Typical causes
- Archiving runs in the browser instead of via cron
- Too many segments are processed in real time
- Raw data is kept forever
- Database and PHP are not sized for the traffic
- Tracking, archiving and reports share a single server
Topology and scaling
The right infrastructure depends on traffic, the number of sites and your availability requirements. I plan with your IT team what goes where.
- Scale vertically: more CPU and memory where it helps, usually the database first
- Scale horizontally: several tracking servers behind a load balancer, tracking requests buffered in a queue (QueuedTracking with Redis)
- Separate roles: a dedicated archiving server, reports and UI separated from tracking
- Relieve the database: a replica for read queries, backups without load on the primary
Database and PHP
- MySQL or MariaDB: InnoDB buffer pool and log sizes that fit the data, indexes, queries and table sizes reviewed, old raw data and archives cleaned up
- PHP: a current version, OPcache, memory limit and run time for archiving, PHP-FPM pools sized for the load
- Archiving: via cron, with sensible intervals and parallel processes where the hardware allows
Analysis
Beyond the technology it is about the questions behind it: where do visitors drop off, which channels bring enquiries, which content works? Together with your team I build reports and dashboards that answer these questions.
FAQ
Frequently asked questions
Scale vertically or horizontally, which is right?
Usually vertically first, meaning more memory and CPU, above all for the database, plus suitable PHP settings and archiving via cron. If that is not enough, I split tracking, archiving and reports onto separate servers and scale tracking horizontally behind a load balancer, with a queue for tracking requests where needed.
When does Matomo need more than one server?
It depends less on the number of page views than on the number of sites, segments and retention periods. Clear signs are archiving that no longer finishes within its window, reports that time out and tracking that slows down during peaks.
What does a second database for read queries bring?
Matomo can send read queries through a separate database connection, for example to a replica. Long report queries and archiving then no longer slow down tracking.
Related
Questions about this?
In an intro call we'll clarify where you stand and whether I'm the right fit.
Your contactPeter Boehlke, Matomo consultant from Munich, 17 years in the Matomo team