Running Matomo in High-Traffic Environments

Matomo is designed to scale from small websites to enterprise deployments that process millions or even billions of tracking requests each month. As traffic volumes increase, infrastructure, database performance, and system configuration become increasingly important.

Without appropriate planning, high-traffic environments may experience slower report generation, tracking delays, longer archive processing times, or increased resource utilisation. This guide provides operational guidance for planning, deploying, and maintaining Matomo in high-traffic environments.

Recommended resources:

• Requirements for Matomo On-Premise
• Pre-deployment checklist
• Post-deployment checklist

1. Planning your deployment

Before sizing your infrastructure, estimate the workload that your Matomo deployment will need to handle. While monthly traffic is an important metric, it is only one factor that affects performance and server requirements. Consider the following:

• Monthly tracking requests (hits): Includes page views, events, downloads, outlinks, Ecommerce interactions and other Tracking API requests. See What is Hit?
• Peak requests per second (RPS): Check existing web server access logs for the rate of requests to Matomo’s tracking endpoint. Filter for POST /matomo.php or GET /matomo.php requests specifically as these are the tracking hits. Everything else (report pages, API calls, static assets) is a different workload. Aggregate requests per second or per minute during a known busy period. The highest sustained rate in that window is the peak RPS figure. See example in real-world benchmarks.
• Number of websites: More tracked websites increase archive processing and reporting workload.
• Number of users: Concurrent users generating reports increase application and database load.
• Segments: Each segment requires additional archive processing and storage.
• Feature usage: Features such as Ecommerce, Custom Reports, Heatmaps & Session Recordings, and other plugins can increase tracking, archive processing, storage, and reporting workloads.
• Data retention: Retaining historical data for longer periods increases database size and maintenance requirements.
• Reporting requirements: Frequent dashboard use, scheduled reports and API requests increase application and archive workload.

2. Traffic volume guidance

Use your estimated workload to select an appropriate starting infrastructure. The recommendations below provide a starting point for common deployment sizes. You should monitor resource utilisation after deployment and adjust your infrastructure as your workload grows.

Note: All archiving recommendations assume browser-triggered archiving is disabled and scheduled archiving is configured using cron.

Each tier should be combined with appropriate server sizing. See Recommended Server Sizing for CPU, RAM, and disk guidance.

Tier 1: Single server

A single well-provisioned server is sufficient at this scale. A single application server with local MySQL/MariaDB, PHP-FPM, OPcache, and SSD storage is suitable for many small to medium deployments. Increase CPU or memory (vertical scaling) before adding more servers.

Move to Tier 2 when:

• Database CPU is consistently above 80%.
• Archive jobs exceed their schedule.
• Reports become noticeably slower.
• You exceed approximately 1-5 million hits/month.

Tier 2: Dedicated database

A single application server remains viable, but separating the database pays off. If required, enable Redis or Memcached for caching and Queued Tracking for sustained traffic peaks.

Move to Tier 3 when:

• PHP-FPM workers are saturated.
• Tracking latency increases.
• Archive jobs take several hours.
• You need redundancy or higher availability.
• Reporting impacts tracking performance.

Tier 3: Distributed/high-scale deployment

Multi-server architecture is required. Tracking, reporting, and archiving workloads should run on dedicated nodes to avoid resource contention.

Requires multiple Matomo application servers behind a load balancer, dedicated MySQL/MariaDB server (or cluster), shared storage for required directories, and dedicated archiving. Use Queued Tracking with Redis and consider database replication.

Tiers 1 and 2 can scale vertically with more resources on fewer servers. Tier 3 requires horizontal scaling, and at that volume it is worth separating tracking servers from reporting and archiving servers to avoid resource contention.

Recommended resources:

• Configure Matomo for High availability multi server environment
• Use the Queued Tracking plugin
• Configure Matomo to use Redis for better Tracking API scalability
• Sample configuration files for high-traffic Matomo deployments

3. Infrastructure recommendations

The following infrastructure components become relevant as deployments grow. Most Tier 1 deployments require only a single server, while Tier 2 and Tier 3 deployments progressively introduce additional components.

3.1 Application servers

Application servers receive tracking requests, serve the Matomo user interface, process API requests, and execute PHP code. Every deployment requires at least one application server, while larger deployments can add additional servers to increase capacity and resilience.

Application servers should be provisioned to support the expected workload. Server performance is influenced by PHP configuration, caching, and the underlying infrastructure. As traffic increases, application servers can be scaled vertically by adding CPU and memory, or horizontally by introducing multiple application servers behind a load balancer.

3.2 Load balancing

Load balancing is required only when running multiple application servers. It distributes incoming requests across application servers, improving scalability, resilience, and 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.
• Shared configuration, plugins and temporary files must be synchronised across all nodes.

This ensures a consistent and stable multi-server environment capable of handling large volumes of traffic.

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

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

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

3.6 Container environments

Matomo is successfully deployed in containerised environments, including Kubernetes and OpenShift (a Kubernetes-based platform), by various enterprise customers. Read the guide on installing Matomo with Docker.

A Matomo Docker image is available and it 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.

4. Operating and tuning Matomo

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

4.1 Web server and PHP-FPM tuning

As traffic increases, monitor PHP-FPM worker utilisation, request queues, and response times. If application servers become CPU or memory constrained, increase available resources (vertical scaling) or add additional application servers behind a load balancer (horizontal scaling). Explore the scalable setup guides.

4.2 MySQL/MariaDB tuning

Database performance is often the primary bottleneck in high-traffic environments. Regularly monitor CPU utilisation, memory usage, connection counts, disk I/O, database growth and slow query logs. If the database becomes resource constrained, consider increasing available resources, separating the database onto its own server, or introducing reader/writer replication for larger deployments.

4.3 CLI archiving prerequisites

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 managing processes via CLI.

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

5.1 CLI archiving

Scheduled CLI archiving pre-processes reports and avoids report generation being triggered by users viewing reports.

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

5.2 Reduce archive workload

In addition to configuring CLI archiving, review the following settings to reduce processing overhead and improve performance in high-traffic environments:

• Exclude unnecessary URL query parameters from reports to reduce the number of unique page URLs stored and processed.
• Regularly review active Segments and Custom Reports, as each additional report increases archive processing time.
• Disable unused plugins.
• Configure data retention settings to remove old visitor logs if long-term raw data is not required.
• Schedule archive jobs outside peak traffic periods where possible to minimise resource contention.

5.3 Archive freshness tuning

Archive freshness determines how frequently Matomo regenerates archive data for today’s reports.

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.

Advanced archiving optimisation for very high-traffic websites

This optimisation is intended for experienced administrators running very large deployments where archive processing exceeds the available schedule. It should only be attempted after monitoring CPU utilisation and archive duration.

If you are running a large Matomo server, with several million hits a day, the archiving can take hours. With some experimentation, parallel processes can shorten the time. Try doing the following for a single website:

1. Find your highest traffic site, and run its archiving in more parallel.
2. First take a baseline: while your normal archiving is being executed, check the percent demand on the CPU capacity on the server of your MySQL database.
3. A well-run server will use 50% to 90% of the CPU capacity. If you are seeing 20% CPU utilisation or less, continue on to the next steps.
4. Set several cron jobs to start core:archive on a single site. Give a five minute delay between them to avoid a spike in resources. For example, if your site of interest is Site 42, set these:

0 * * * * php console core:archive --force-idsites=42 --concurrent-requests-per-website=6
5 * * * * php console core:archive --force-idsites=42 --concurrent-requests-per-website=6
10 * * * * php console core:archive --force-idsites=42 --concurrent-requests-per-website=6

Increasing the number of parallel archive processes beyond two or three often produces diminishing returns because of database locking and contention. Monitor CPU utilisation, archive duration and database performance after each change.

Some plugins also generate segment archives. If a specific plugin contributes significantly to archive processing time, you can selectively disable segment archiving for that plugin.

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.

7. Monitoring and troubleshooting

After deployment, monitor your Matomo environment regularly to identify performance bottlenecks before they affect tracking or reporting. Focus on application servers, the database, and archiving performance.

7.1 Key metrics to monitor

7.2 Common symptoms and recommended actions

High-traffic Matomo deployments should be monitored continuously. Review application server, database and archiving performance regularly, and adjust your infrastructure as traffic, reporting requirements and data volumes grow over time.