Running Matomo in High-Traffic Environments

Matomo is built to scale from small websites to enterprise environments processing millions to billions of tracking actions per month.

High-traffic websites can introduce challenges around performance and scalability. So, without careful infrastructure planning, Matomo may experience slow reporting, tracking delays, or degraded system performance.

This guide serves as a central reference for partners and enterprise clients planning, deploying, and managing high-traffic Matomo environments. It complements existing Matomo documentation, which you can access in Related Topics at the end of this guide.

Infrastructure recommendations for high traffic

High-traffic Matomo deployments require careful infrastructure planning to maintain system stability, scalability, and performance. This section outlines key considerations:

Load balancing

Small to medium high-traffic sites may run successfully on a single server with sufficient CPU, memory, and disk capacity. However, for large or enterprise deployments, a multi-server environment is recommended to provide scalability, stability, and high availability.

In a load-balanced Matomo setup:

  • All servers must run the same codebase and Matomo version.
  • All Matomo application servers must connect to the same MySQL or MariaDB database.
  • All nodes must have access to shared storage for key folders:
    • config/ (configuration file synchronisation)
    • plugins/ (identical plugin sets)
    • tmp/ (temporary and cache files, often handled via shared storage such as NFS or GlusterFS)

This ensures a consistent and stable multi-server environment capable of handling large volumes of traffic. Read more about Does Matomo work in a load balanced environment?

Sticky sessions

Sticky sessions are not required in standard Matomo setups, as session data can be stored in the database. However, if you use the optional Queued Tracking plugin with Redis, sticky sessions are recommended to ensure that tracking requests for the same visitor are consistently processed by the same server.

Load balancer options

Popular load balancers include:

  • Nginx (reverse proxy and load balancer)
  • HAProxy (high-performance TCP/HTTP load balancer)
  • AWS Application Load Balancer (ALB) for cloud deployments

Matomo works with any load balancer capable of forwarding HTTP(S) traffic to multiple backend servers.

Caching layers

Caching improves performance and reduces load on Matomo servers, especially in high-traffic environments. Multiple caching layers can be applied.

PHP opcode caching

Enable OPcache in PHP to avoid repeated compilation of PHP scripts. OPcache is included by default in modern PHP versions and significantly improves response times.

Object and session caching

Use Redis or Memcached to cache session data and other frequently accessed data. Redis is also recommended if using the Queued Tracking plugin to buffer tracking requests.

CDN use

For cloud or global deployments, serve static assets (e.g. JavaScript files, CSS, images) via a Content Delivery Network (CDN). This reduces load on the Matomo web servers and improves content delivery speeds for global visitors.

You may also configure reverse proxy caching (such as Nginx fastcgi_cache) for certain types of responses, but this requires careful testing to avoid caching personalised or dynamic tracking data.

Scaling approaches

Matomo can be scaled vertically or horizontally depending on traffic volume and infrastructure goals.

Vertical scaling

For small to medium high-traffic websites, increasing the resources of a single server (CPU, RAM, SSD storage) is often sufficient. This provides a simple and cost-effective solution up to a certain volume of actions per month.

Horizontal scaling

For large or enterprise environments, horizontal scaling is recommended:

  • Add multiple Matomo application servers behind a load balancer.
  • Use a single MySQL or MariaDB database (or cluster) shared by all application servers.
  • Consider separating tracking servers (handling incoming tracking requests) from reporting/API servers to optimise resource usage.
  • Use Redis or Memcached for session and cache management if required.

Typical high-traffic configurations include:

  • Single server: Suitable for smaller sites with adequate hardware.
  • Multi-web server setup: Two or more Matomo servers with shared storage and a single database.
  • Enterprise architecture: Multiple web servers for tracking, dedicated servers for reporting and archiving, load balancers, and a database cluster for high availability and failover.

The design should consider expected traffic volumes, peak loads, and operational complexity.

File storage requirements

In multi-server Matomo environments, consistent file storage across all application nodes is essential for stability and performance.

Shared folders

The following folders must be consistent and accessible by all Matomo servers:

  • config/: Contains critical configuration files. Changes to settings must be synchronised across all nodes.
  • plugins/: All servers must run the same plugin set and version.
  • tmp/: Stores temporary files, compiled templates, reports, and tracking caches. Its contents can be safely regenerated if lost.
  • Regularly back up the config/ and plugins/ folders.

Storage options

  • Use a shared file system such as NFS, GlusterFS, or CephFS to provide consistent access.
  • In containerised environments, persistent volumes must be used for these folders.
  • Avoid storing these folders on local disk in multi-server setups.
  • Ensure the shared storage is reliable and offers high I/O performance to prevent bottlenecks.

Matomo in container environments

Matomo is successfully deployed in containerised environments, including Kubernetes and OpenShift (a Kubernetes-based platform), by various enterprise customers.

A Matomo Docker image exists and is updated automatically with each new stable release. Partners are advised to actively monitor and secure dependencies, as the image is maintained by the Matomo community and not officially supported by Matomo core development.

When deploying Matomo in containers, ensure that critical directories (config/, plugins/, and tmp/) are backed by persistent storage to maintain data consistency across containers and pods.

Server and database tuning best practices

Optimal server and database configuration is critical for maintaining performance and stability in high-traffic Matomo environments:

Web server and PHP-FPM tuning

  • Use PHP-FPM with sufficient child processes to handle concurrent requests.
  • Enable PHP OPcache to reduce CPU load and improve script execution times.
  • Set appropriate values for max_execution_time, memory_limit, and post_max_size based on expected traffic and reporting workloads.
  • Use HTTPS for all web traffic.

MySQL/MariaDB tuning

  • Increase max_connections to handle simultaneous requests.
  • Optimise innodb_buffer_pool_size (typically 60–80% of RAM on dedicated DB servers).
  • Use fast SSD storage to improve disk I/O performance.
  • Monitor and review slow query logs regularly to identify and address performance bottlenecks.
  • For large environments, consider master-replica database setups for high availability and reporting scale.

Operating system considerations

  • Provision sufficient CPU, memory, and disk I/O capacity for anticipated load.
  • Continuously monitor system performance (CPU, RAM, disk, DB connections).
  • Keep all system packages and PHP extensions updated.

CLI requirements

Matomo relies on scheduled tasks for reporting and data processing. The PHP function to execute system commands (proc_open, shell_exec) must be enabled. Read more on How to make the diagnostic “Managing processes via CLI” display Ok.

Archiving strategies for performance

Matomo generates reports by processing raw tracking data into aggregated report tables at scheduled intervals. This section explains how to configure and optimise the archiving process to ensure stable reporting in large-scale deployments.

CLI archiving

  • Run the core:archive command regularly to process reports.
  • Schedule the command based on data volume and reporting requirements (hourly or multiple times daily).
  • Disable browser-triggered archiving by setting enable_browser_archiving_triggering = 0 in config.ini.php.

Archive freshness tuning

The time_before_today_archive_considered_outdated setting controls how often Matomo reprocesses data for today’s reports. The default is 10 seconds and on high-traffic environments, you can increase this value (e.g. 3600 seconds for hourly processing) to reduce server load. Read more about the Optimal setting for time_before_today_archive_considered_outdated.

Additional recommendations

  • To ensure consistent reporting and system stability, high-traffic Matomo deployments should configure automatic archiving using a scheduled cron task.
  • The use of large numbers of Segments and Custom Reports significantly increases archiving time in high-traffic environments. To minimise processing overhead, only enable essential Segments and avoid unnecessary Custom Reports.
  • On very large deployments, archive jobs may run for several hours due to high traffic volumes and large datasets. To reduce the risk of delayed reporting data or degraded tracking performance, schedule archiving tasks outside of peak traffic periods.
  • Learn about setting up auto-archiving of your reports.

Real-world benchmarks

Matomo is actively deployed in environments ranging from small websites to enterprise platforms processing millions to hundreds of millions of actions per month. Some installations report peak loads exceeding 5,000 hits per second and sustained volumes over 150 million actions monthly.

The following examples have been observed across high-traffic Matomo deployments:

  • 24 million actions per month (on-premises)
  • 100 million actions per month:
    • 8.36 million visits
    • 43.57 million pageviews
    • 100.78 million actions
  • Peak tracking spikes of 5,000 hits per second
  • Other enterprise installations reporting:
    • 10 million hits per month
    • 135 million hits per month
    • 150 million hits per month

Upper boundary observed

In large enterprise use cases, Matomo MySQL database setups have been observed to support up to approximately 2 billion actions per month. Performance at this scale depends on careful tuning of the database, optimisation of tracking and reporting workloads, and efficient use of archiving strategies.

These examples are provided for informational purposes and do not represent guaranteed performance levels for any specific deployment.