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

Nginx as a High-Performance Frontend for WordPress

When deploying WordPress on AWS, Nginx is the de facto standard for a high-performance web server. Its event-driven, asynchronous architecture excels at handling concurrent connections, making it ideal for serving static assets and proxying dynamic requests to your application backend. This section details critical Nginx tuning parameters for WordPress.

Optimizing Worker Processes and Connections

The `worker_processes` directive controls how many worker processes Nginx spawns. Setting this to `auto` allows Nginx to determine the optimal number based on available CPU cores, which is generally recommended. The `worker_connections` directive limits the number of simultaneous connections a single worker process can handle. This value should be set high enough to accommodate peak traffic, considering that each connection consumes a file descriptor.

A common starting point for `worker_connections` is 1024, but this can be increased significantly. Ensure your system’s file descriptor limit (`ulimit -n`) is also set appropriately high. You can check the current limit with ulimit -n and set it temporarily with ulimit -n 65535. For persistent changes, modify /etc/security/limits.conf.

Enabling Gzip Compression

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

Nginx Configuration Snippet for Gzip

Add the following to your nginx.conf or a dedicated conf file in conf.d/:

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
gzip_disable "msie6"; # Disable for older IE versions

Leveraging Browser Caching

Instructing browsers to cache static assets reduces server load and improves perceived performance for repeat visitors. Use the `expires` directive to set cache control headers.

Nginx Configuration Snippet for Caching

This configuration caches static assets for a generous period. Adjust as needed based on your deployment strategy.

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

Optimizing Keep-Alive Connections

HTTP Keep-Alive allows a TCP connection to remain open for multiple HTTP requests, reducing the overhead of establishing new connections for each request. Tune keepalive_timeout and keepalive_requests.

Nginx Configuration Snippet for Keep-Alive

keepalive_timeout 65;
keepalive_requests 1000;

Proxying to PHP-FPM (or Gunicorn for non-PHP backends)

For WordPress, Nginx acts as a reverse proxy to PHP-FPM. For other application stacks, it would proxy to Gunicorn (Python), Puma (Ruby), etc. The key is efficient connection management and request buffering.

Nginx Configuration Snippet for PHP-FPM Proxy

Ensure the fastcgi_pass directive points to your PHP-FPM socket or address. The fastcgi_read_timeout should be set to a reasonable value to prevent long-running PHP scripts from timing out prematurely at the Nginx level, though PHP-FPM’s own timeouts are also critical.

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    # With php-fpm (or other unix sockets):
    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    # Or with TCP/IP:
    # fastcgi_pass 127.0.0.1:9000;
    fastcgi_read_timeout 300s; # Allow longer execution for complex PHP tasks
}

Tuning PHP-FPM for WordPress Performance

PHP-FPM (FastCGI Process Manager) is the engine that executes your PHP code. Its configuration directly impacts WordPress performance. The primary tuning parameters revolve around process management and resource allocation.

Process Manager Settings: Static vs. Dynamic

PHP-FPM offers three process management modes: static, dynamic, and ondemand. For most WordPress deployments on AWS with predictable traffic patterns, dynamic or static are preferred over ondemand (which can introduce latency on initial requests).

Dynamic Process Management

dynamic mode is a good balance. It starts with a few processes and spawns more as needed, up to a defined maximum. This conserves resources during low traffic but scales up for demand.

PHP-FPM Configuration Snippet (www.conf)

Locate your PHP-FPM pool configuration file (e.g., /etc/php/7.4/fpm/pool.d/www.conf). Adjust these parameters based on your server’s CPU and RAM.

pm = dynamic
pm.max_children = 50       ; Max number of children that can be started.
pm.start_servers = 5       ; Number of children created at startup.
pm.min_spare_servers = 2   ; Min number of idle respawned after first start.
pm.max_spare_servers = 10  ; Max number of idle respawned after first start.
pm.process_idle_timeout = 10s; The timeout for serving requests with a persistent processes.
pm.max_requests = 500      ; Max number of requests each child process should serve. Resetting helps prevent memory leaks.

Static Process Management

static mode pre-forks a fixed number of processes. This offers the most predictable performance as processes are always ready, but it can be resource-intensive if the number is set too high for idle periods.

PHP-FPM Configuration Snippet (www.conf)

For static, you primarily set pm.max_children. The other pm.* directives related to dynamic spawning are ignored.

pm = static
pm.max_children = 30       ; Fixed number of children to serve requests.
pm.max_requests = 500      ; Max number of requests each child process should serve.

Recommendation: Start with dynamic and monitor your server’s CPU and memory usage. If you see consistent high load and want to eliminate any potential latency from process spawning, consider switching to static after profiling. A good rule of thumb for pm.max_children (for both modes) is to set it such that the total memory usage of all child processes doesn’t exceed 70-80% of your available RAM. Each PHP-FPM worker can consume 20-50MB or more depending on WordPress plugins and theme complexity.

Tuning PHP Settings

Key PHP settings in php.ini (or within the PHP-FPM pool configuration) that affect WordPress performance include:

PHP Configuration Snippet (php.ini or www.conf)

memory_limit = 256M      ; Increase if WordPress or plugins require more.
upload_max_filesize = 64M  ; Adjust based on expected media uploads.
post_max_size = 64M        ; Should be >= upload_max_filesize.
max_execution_time = 120   ; Max execution time for scripts. Crucial for long-running tasks.
max_input_vars = 3000      ; Increase if you encounter "Too many input variables" errors, common with many theme options or plugin settings.

These settings can often be overridden within the PHP-FPM pool configuration file (www.conf) using directives like php_admin_value[memory_limit] = 256M. This is often preferred as it isolates these settings to the FPM pool.

MongoDB Performance Tuning for WordPress Plugins

While WordPress traditionally uses MySQL, many plugins leverage MongoDB for specific functionalities (e.g., caching, search, analytics). Optimizing MongoDB is crucial if it’s part of your stack.

Storage Engine: WiredTiger

WiredTiger is the default and recommended storage engine for MongoDB. It offers excellent compression and concurrency. Ensure you are using it and understand its configuration.

Memory Allocation and Caching

MongoDB heavily relies on RAM for caching data and indexes. The primary configuration parameter is storage.wiredTiger.engineConfig.cacheSizeGB. A common recommendation is to allocate 50% of system RAM to the WiredTiger cache, ensuring enough remains for the OS and other processes.

MongoDB Configuration Snippet (mongod.conf)

Edit your mongod.conf file (typically located at /etc/mongod.conf).

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

Note: If your MongoDB instance is running on an EC2 instance with EBS volumes, ensure you are using appropriate EBS volume types (e.g., `gp3` or `io1`/`io2`) and provisioned IOPS if necessary for high-throughput workloads.

Indexing Strategies

Proper indexing is paramount for MongoDB query performance. Identify slow queries using MongoDB’s profiler and add appropriate indexes. For WordPress plugins, this often involves indexing fields used in `find()` and `aggregate()` operations.

Example: Creating an Index

If a plugin frequently queries a collection named `plugin_analytics` on a field `user_id` and a timestamp `event_time`, you might create a compound index:

db.plugin_analytics.createIndex( { user_id: 1, event_time: -1 } )

Use db.collection.getIndexes() to view existing indexes and db.collection.explain("executionStats").find(...) to analyze query performance and identify missing indexes.

Connection Pooling

Ensure your WordPress plugins are configured to use connection pooling when interacting with MongoDB. This reuses database connections, reducing the overhead of establishing new ones for each request. Most MongoDB drivers and ORMs handle this automatically, but it’s worth verifying in plugin documentation or code if performance issues arise.

Query Optimization

Avoid using $ne (not equal) or $nin (not in) operators on indexed fields where possible, as they can sometimes prevent index usage. Prefer explicit inclusion criteria. Also, be mindful of the number of fields returned using projection to minimize data transfer.

Putting It All Together: AWS Deployment Considerations

When deploying this stack on AWS, consider the following:

• EC2 Instance Sizing: Choose instance types that balance CPU, RAM, and network I/O appropriate for your traffic. For compute-bound PHP-FPM, consider compute-optimized instances. For memory-intensive MongoDB, memory-optimized instances are key.
• EBS Volumes: For MongoDB, use `io1`/`io2` or `gp3` with provisioned IOPS/throughput if disk I/O is a bottleneck. For Nginx/PHP-FPM, `gp3` is usually sufficient.
• Security Groups: Restrict access to Nginx (port 80/443) from the internet. Limit access to PHP-FPM and MongoDB to only the necessary internal EC2 instances (e.g., Nginx server for PHP-FPM, application servers for MongoDB).
• Monitoring: Implement robust monitoring using CloudWatch, Prometheus/Grafana, or Datadog. Track CPU utilization, memory usage, network traffic, disk I/O, Nginx request rates, PHP-FPM process counts, and MongoDB query performance.
• Load Balancing: For high availability and scalability, use an AWS Application Load Balancer (ALB) in front of multiple Nginx instances.
• Database Management: For MySQL, consider AWS RDS. For MongoDB, consider DocumentDB (if compatible) or self-managing on EC2 with appropriate replication and backup strategies.

By meticulously tuning each layer of your WordPress stack—Nginx, PHP-FPM, and MongoDB—you can achieve significant performance gains and build a robust, scalable infrastructure on AWS.