Vengala Vinay

Having 12+ Years of Experience in Software Development

Home » The Ultimate DevOps Playbook: Tuning Nginx, Gunicorn/FPM, and MongoDB on DigitalOcean for WordPress

The Ultimate DevOps Playbook: Tuning Nginx, Gunicorn/FPM, and MongoDB on DigitalOcean for WordPress

The pm directive controls how PHP-FPM manages child processes. Common options are static, dynamic, and ondemand. For a WordPress site with consistent traffic, dynamic or static often yield better performance than ondemand.

  • pm = dynamic: This is often a good balance. It starts with a minimum number of processes and scales up to a maximum as needed.
  • pm = static: This keeps a fixed number of processes running at all times. It can be more performant if you have predictable, high traffic, but can waste resources during low traffic periods.

Key directives for dynamic PM:

; /etc/php/8.1/fpm/pool.d/www.conf (example for PHP 8.1)

pm = dynamic
pm.max_children = 100       ; Max number of children that can be started.
pm.start_servers = 10       ; Number of children created at startup.
pm.min_spare_servers = 5    ; Number of children to keep idle.
pm.max_spare_servers = 20   ; Number of children to keep idle.
pm.process_idle_timeout = 10s ; The timeout for idle processes.
pm.max_requests = 500       ; Max number of requests each child process will serve.

For static PM:

; /etc/php/8.1/fpm/pool.d/www.conf (example for PHP 8.1)

pm = static
pm.max_children = 150       ; Fixed number of children.
pm.max_requests = 500       ; Max number of requests each child process will serve.

Determining max_children: A common heuristic is to calculate based on available RAM. Each PHP-FPM worker can consume a certain amount of memory. Sum the memory usage of your web server (Nginx), database (MySQL/MariaDB), and estimate PHP-FPM worker memory. Divide total available RAM by estimated worker memory to get a rough upper bound for max_children. Monitor memory usage closely after tuning.

PHP Configuration (php.ini)

While not directly part of PHP-FPM’s process management, key settings in php.ini (e.g., /etc/php/[version]/fpm/php.ini) impact performance. Ensure memory_limit is sufficient for your WordPress plugins and theme, and consider enabling OPcache.

; /etc/php/8.1/fpm/php.ini (example)

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M

; OPcache settings for significant performance boost
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128 ; MB
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.enable_file_override=0

MongoDB Performance Tuning for WordPress (if applicable)

While WordPress traditionally uses MySQL/MariaDB, some plugins or custom solutions might leverage MongoDB. Tuning MongoDB is crucial for efficient data retrieval. We’ll focus on indexing and configuration.

Indexing Strategy

Proper indexing is paramount. Analyze your query patterns using MongoDB’s explain() method to identify slow queries and create appropriate indexes. For example, if you frequently query a collection named posts by author_id and status:

db.posts.createIndex( { author_id: 1, status: 1 } )

Consider compound indexes for queries that filter on multiple fields. Regularly review and optimize indexes using tools like mongotop and mongostat.

MongoDB Configuration Tuning (mongod.conf)

The primary configuration file is typically /etc/mongod.conf. Key parameters to consider:

Storage Engine and Cache Size

Ensure you are using the WiredTiger storage engine (default in modern MongoDB versions). The storage.wiredTiger.engineConfig.cacheSizeGB setting is critical. Allocate a significant portion of your server’s RAM to this cache, leaving enough for the OS, Nginx, and PHP-FPM. A common recommendation is to allocate 50-75% of available RAM to the WiredTiger cache, but this requires careful monitoring.

# /etc/mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4 # Example: Allocate 4GB for a server with 8GB RAM
    collectionConfig:
      blockSize: 4KB
    indexConfig:
      prefixCompression: true

# ... other configurations

Connection Pooling and Network

While not directly in mongod.conf, ensure your application’s MongoDB driver is configured with appropriate connection pooling settings. For server-level tuning, ensure network interfaces are optimized and firewalls are not introducing latency.

Monitoring and Profiling

Regularly monitor MongoDB performance using tools like mongostat, mongotop, and the database profiler. The profiler can help identify slow operations and inefficient queries.

// Enable the profiler (for a specific database)
db.setProfilingLevel( 1, { slowms: 100 } ) // Profile slow operations (e.g., > 100ms)

// View slow operations
db.system.profile.find().pretty()

// Disable profiling
db.setProfilingLevel( 0 )

Putting It All Together: A DigitalOcean Deployment Example

On a DigitalOcean Droplet (e.g., 4GB RAM, 2 vCPUs), a typical setup might involve:

  • Nginx: worker_processes auto, worker_connections 4096, Gzip enabled, HTTP/2 enabled.
  • PHP-FPM (e.g., PHP 8.1): pm = dynamic, pm.max_children = 75 (adjust based on RAM), pm.start_servers = 15, pm.min_spare_servers = 8, pm.max_spare_servers = 30.
  • PHP.ini: memory_limit = 192M, OPcache enabled with generous memory allocation.
  • MySQL/MariaDB: Tuned innodb_buffer_pool_size (e.g., 1.5GB for 4GB RAM Droplet), query_cache_size (if applicable and beneficial for your workload).
  • MongoDB (if used): cacheSizeGB set to ~3GB, with appropriate indexing.

Important Note: These are starting points. The optimal configuration is highly dependent on your specific WordPress site’s plugins, theme, traffic patterns, and the Droplet’s resources. Continuous monitoring and iterative tuning are essential for maintaining peak performance.

Nginx as a High-Performance Frontend for WordPress

When deploying WordPress on DigitalOcean, Nginx serves as an excellent choice for a web server due to its event-driven architecture, making it highly efficient for handling concurrent connections. Proper tuning of Nginx is critical for maximizing throughput and minimizing latency. We’ll focus on key directives that impact performance.

Nginx Configuration Tuning

The primary configuration file for Nginx is typically located at /etc/nginx/nginx.conf. We’ll focus on tuning the http block and worker process settings.

Worker Processes and Connections

The worker_processes directive determines how many worker processes Nginx will spawn. Setting this to auto is generally recommended, allowing Nginx to detect the number of CPU cores and utilize them efficiently. The worker_connections directive sets the maximum number of simultaneous connections that each worker process can handle. A common starting point is 1024, but this can be increased based on server resources and expected load.

# /etc/nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 4096; # Increased from default 1024
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # ... other http configurations
}

Gzip Compression

Enabling Gzip compression significantly reduces the size of text-based assets (HTML, CSS, JavaScript), leading to faster page load times. Ensure it’s enabled and configured appropriately.

# Inside the http block of nginx.conf

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6; # Compression level (1-9)
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Browser Caching

Leveraging browser caching with appropriate Expires or Cache-Control headers allows clients to store static assets locally, reducing server load and improving perceived performance for repeat visitors.

# Inside the http block of nginx.conf

location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|webp)$ {
    expires 365d;
    add_header Cache-Control "public, no-transform";
}

HTTP/2 and TLS Optimization

Enabling HTTP/2 can provide significant performance benefits through multiplexing, header compression, and server push. Ensure your SSL/TLS configuration is also optimized for speed.

# Inside your server block for SSL/TLS

listen 443 ssl http2;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
# ... other ssl directives

Gunicorn/PHP-FPM: The Application Server Layer

For WordPress, the application server layer is typically handled by PHP. When using Nginx as a frontend, PHP-FPM (FastCGI Process Manager) is the standard and most performant way to interface with PHP. If you’re using a Python-based framework for a different application, Gunicorn is a common WSGI HTTP Server. We’ll focus on PHP-FPM tuning for WordPress.

PHP-FPM Configuration Tuning

PHP-FPM configuration files are usually found in /etc/php/[version]/fpm/php-fpm.conf and /etc/php/[version]/fpm/pool.d/www.conf. The pool.d/www.conf file is where most tuning occurs.

Process Manager Settings

The pm directive controls how PHP-FPM manages child processes. Common options are static, dynamic, and ondemand. For a WordPress site with consistent traffic, dynamic or static often yield better performance than ondemand.

  • pm = dynamic: This is often a good balance. It starts with a minimum number of processes and scales up to a maximum as needed.
  • pm = static: This keeps a fixed number of processes running at all times. It can be more performant if you have predictable, high traffic, but can waste resources during low traffic periods.

Key directives for dynamic PM:

; /etc/php/8.1/fpm/pool.d/www.conf (example for PHP 8.1)

pm = dynamic
pm.max_children = 100       ; Max number of children that can be started.
pm.start_servers = 10       ; Number of children created at startup.
pm.min_spare_servers = 5    ; Number of children to keep idle.
pm.max_spare_servers = 20   ; Number of children to keep idle.
pm.process_idle_timeout = 10s ; The timeout for idle processes.
pm.max_requests = 500       ; Max number of requests each child process will serve.

For static PM:

; /etc/php/8.1/fpm/pool.d/www.conf (example for PHP 8.1)

pm = static
pm.max_children = 150       ; Fixed number of children.
pm.max_requests = 500       ; Max number of requests each child process will serve.

Determining max_children: A common heuristic is to calculate based on available RAM. Each PHP-FPM worker can consume a certain amount of memory. Sum the memory usage of your web server (Nginx), database (MySQL/MariaDB), and estimate PHP-FPM worker memory. Divide total available RAM by estimated worker memory to get a rough upper bound for max_children. Monitor memory usage closely after tuning.

PHP Configuration (php.ini)

While not directly part of PHP-FPM’s process management, key settings in php.ini (e.g., /etc/php/[version]/fpm/php.ini) impact performance. Ensure memory_limit is sufficient for your WordPress plugins and theme, and consider enabling OPcache.

; /etc/php/8.1/fpm/php.ini (example)

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M

; OPcache settings for significant performance boost
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128 ; MB
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.enable_file_override=0

MongoDB Performance Tuning for WordPress (if applicable)

While WordPress traditionally uses MySQL/MariaDB, some plugins or custom solutions might leverage MongoDB. Tuning MongoDB is crucial for efficient data retrieval. We’ll focus on indexing and configuration.

Indexing Strategy

Proper indexing is paramount. Analyze your query patterns using MongoDB’s explain() method to identify slow queries and create appropriate indexes. For example, if you frequently query a collection named posts by author_id and status:

db.posts.createIndex( { author_id: 1, status: 1 } )

Consider compound indexes for queries that filter on multiple fields. Regularly review and optimize indexes using tools like mongotop and mongostat.

MongoDB Configuration Tuning (mongod.conf)

The primary configuration file is typically /etc/mongod.conf. Key parameters to consider:

Storage Engine and Cache Size

Ensure you are using the WiredTiger storage engine (default in modern MongoDB versions). The storage.wiredTiger.engineConfig.cacheSizeGB setting is critical. Allocate a significant portion of your server’s RAM to this cache, leaving enough for the OS, Nginx, and PHP-FPM. A common recommendation is to allocate 50-75% of available RAM to the WiredTiger cache, but this requires careful monitoring.

# /etc/mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4 # Example: Allocate 4GB for a server with 8GB RAM
    collectionConfig:
      blockSize: 4KB
    indexConfig:
      prefixCompression: true

# ... other configurations

Connection Pooling and Network

While not directly in mongod.conf, ensure your application’s MongoDB driver is configured with appropriate connection pooling settings. For server-level tuning, ensure network interfaces are optimized and firewalls are not introducing latency.

Monitoring and Profiling

Regularly monitor MongoDB performance using tools like mongostat, mongotop, and the database profiler. The profiler can help identify slow operations and inefficient queries.

// Enable the profiler (for a specific database)
db.setProfilingLevel( 1, { slowms: 100 } ) // Profile slow operations (e.g., > 100ms)

// View slow operations
db.system.profile.find().pretty()

// Disable profiling
db.setProfilingLevel( 0 )

Putting It All Together: A DigitalOcean Deployment Example

On a DigitalOcean Droplet (e.g., 4GB RAM, 2 vCPUs), a typical setup might involve:

  • Nginx: worker_processes auto, worker_connections 4096, Gzip enabled, HTTP/2 enabled.
  • PHP-FPM (e.g., PHP 8.1): pm = dynamic, pm.max_children = 75 (adjust based on RAM), pm.start_servers = 15, pm.min_spare_servers = 8, pm.max_spare_servers = 30.
  • PHP.ini: memory_limit = 192M, OPcache enabled with generous memory allocation.
  • MySQL/MariaDB: Tuned innodb_buffer_pool_size (e.g., 1.5GB for 4GB RAM Droplet), query_cache_size (if applicable and beneficial for your workload).
  • MongoDB (if used): cacheSizeGB set to ~3GB, with appropriate indexing.

Important Note: These are starting points. The optimal configuration is highly dependent on your specific WordPress site’s plugins, theme, traffic patterns, and the Droplet’s resources. Continuous monitoring and iterative tuning are essential for maintaining peak performance.

Recent Posts

Top Categories

Our Products

Our Services