Vengala Vinay

Having 9+ Years of Experience in Software Development

Home » The Ultimate DevOps Playbook: Tuning Nginx, Gunicorn/FPM, and MySQL on OVH for Magento 2

The Ultimate DevOps Playbook: Tuning Nginx, Gunicorn/FPM, and MySQL on OVH for Magento 2

Nginx Configuration for Magento 2 on OVH

Optimizing Nginx for a high-traffic Magento 2 instance on OVH requires a multi-faceted approach, focusing on efficient request handling, caching, and resource management. We’ll start with core directives and then delve into specific Magento 2 considerations.

Core Nginx Performance Tuning

The nginx.conf file, typically located at /etc/nginx/nginx.conf, is the primary configuration point. Key global settings to adjust include:

  • worker_processes: Set this to the number of CPU cores available. On OVH dedicated servers, this is crucial for parallel request processing.
  • worker_connections: This defines the maximum number of simultaneous connections a worker process can handle. A common starting point is 4096, but this can be increased based on server load and OS limits (ulimit -n).
  • multi_accept: Enable this to allow workers to accept multiple connections at once.
  • keepalive_timeout: Reduces overhead by keeping connections open for a short period. A value between 65 and 120 seconds is often suitable.
  • sendfile: Set to on to enable efficient file transfer from the OS kernel.
  • tcp_nopush and tcp_nodelay: Set to on to improve network packet efficiency.

Here’s a sample snippet for the events block:

events {
    worker_connections 4096;
    multi_accept on;
}

Magento 2 Specific Nginx Optimizations

Magento 2 benefits significantly from Nginx’s caching capabilities and specific configuration directives to handle its complex request routing and static asset serving.

Static File Caching and Compression

Leverage Nginx’s expires directive to set appropriate cache headers for static assets. This reduces server load by allowing browsers and intermediate caches to serve these files directly. Enable Gzip compression for text-based assets.

location ~* ^/(images|js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot) {
    expires 30d;
    add_header Cache-Control "public, no-transform";
    access_log off;
    gzip_static on; # Requires pre-generated gzipped files
    gzip_vary on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
}

PHP-FPM Configuration for Magento 2

Magento 2 is typically served by PHP-FPM. The configuration of PHP-FPM pools, often found in /etc/php/[version]/fpm/pool.d/www.conf, is critical for performance. For production environments, a dynamic process manager is generally recommended.

Tuning the PHP-FPM Pool

Key directives to adjust:

  • pm: Set to dynamic.
  • pm.max_children: The maximum number of child processes that will be spawned. This should be calculated based on available RAM and the memory footprint of your PHP processes. A common formula is (Total RAM - Reserved RAM for OS/DB) / Average PHP Process Memory.
  • pm.start_servers: The number of child processes started when the pool starts.
  • pm.min_spare_servers: The minimum number of idle supervisor processes.
  • pm.max_spare_servers: The maximum number of idle supervisor processes.
  • request_terminate_timeout: Crucial for preventing runaway scripts. Set to a reasonable value like 60 or 120 seconds.
  • pm.process_idle_timeout: The number of seconds after which an idle process will be killed.

A sample configuration for a dynamic pool:

pm = dynamic
pm.max_children = 150
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30
request_terminate_timeout = 120
pm.process_idle_timeout = 10s

Remember to restart PHP-FPM after making changes: sudo systemctl restart php[version]-fpm.

MySQL/MariaDB Tuning for Magento 2

Magento 2 is a database-intensive application. Optimizing MySQL/MariaDB is paramount. The primary configuration file is typically my.cnf or files within /etc/mysql/conf.d/.

Key MySQL Performance Variables

Focus on these critical variables:

  • innodb_buffer_pool_size: This is the most important setting for InnoDB. It should be set to 70-80% of your available RAM on a dedicated database server.
  • innodb_log_file_size: Larger log files can improve write performance but increase recovery time. A common starting point is 256M or 512M.
  • innodb_flush_log_at_trx_commit: Setting this to 2 (instead of the default 1) can significantly improve write performance at a slight risk of losing the last second of transactions in a crash. For most Magento sites, this is an acceptable trade-off.
  • query_cache_type and query_cache_size: While the query cache is deprecated in newer MySQL versions and often problematic with frequent writes, it might offer some benefit for read-heavy Magento sites. If enabled, set a reasonable size (e.g., 64M to 128M). For MySQL 8+, this should be disabled.
  • max_connections: Ensure this is high enough to accommodate your application’s needs, but not so high that it exhausts server memory.
  • tmp_table_size and max_heap_table_size: These control the maximum size of in-memory temporary tables.

Example my.cnf snippet (adjust RAM values based on your OVH server specs):

[mysqld]
innodb_buffer_pool_size = 8G  # Example for a server with 16GB RAM
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
query_cache_type = 1
query_cache_size = 128M
max_connections = 300
tmp_table_size = 64M
max_heap_table_size = 64M

After modifying my.cnf, restart the MySQL service: sudo systemctl restart mysql.

Monitoring and Diagnostics

Continuous monitoring is key to identifying bottlenecks. Utilize tools like:

  • Nginx: nginx -t for syntax checks, tail -f /var/log/nginx/access.log and error.log for real-time analysis, and Nginx Amplify or Prometheus/Grafana for historical metrics.
  • PHP-FPM: Check PHP-FPM logs for errors. Use htop or top to monitor PHP-FPM process counts and memory usage.
  • MySQL: SHOW GLOBAL STATUS; and SHOW ENGINE INNODB STATUS; are invaluable. Tools like Percona Monitoring and Management (PMM) or Prometheus with mysqld_exporter provide comprehensive insights.
  • System Resources: vmstat, iostat, and sar are essential for understanding CPU, memory, and I/O utilization.

For Magento 2 specifically, analyze slow query logs in MySQL and use tools like New Relic or Blackfire.io for application-level performance profiling.