The Ultimate DevOps Playbook: Tuning Nginx, Gunicorn/FPM, and DynamoDB on AWS for WooCommerce

Nginx Configuration for High-Traffic WooCommerce

Optimizing Nginx for a WooCommerce site involves a multi-pronged approach, focusing on efficient static file serving, robust caching, and intelligent request handling. For a high-traffic environment, we’ll prioritize reducing load on the application servers (Gunicorn/FPM) by offloading as much as possible to Nginx.

Static File Serving and Compression

Ensure Nginx is configured to serve static assets (images, CSS, JS) directly and efficiently. Enable Gzip compression for text-based assets to reduce bandwidth. Set appropriate cache headers to leverage browser caching.

A typical Nginx configuration snippet for static assets might look like this:

location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|webp|woff|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
    gzip_static on; # Requires pre-compressed assets
    # Or use dynamic gzip compression if pre-compression isn't feasible
    # 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 Compression Tuning

For dynamic content, fine-tune Gzip compression. A balance is needed between CPU usage for compression and bandwidth savings. Level 6 is often a good compromise.

# Place these directives in your http block or server block
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
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;

Client Body and Timeout Settings

For WooCommerce, especially during checkout or when handling file uploads, increasing client body size limits and timeouts can prevent errors. Be cautious with these settings to avoid resource exhaustion.

client_max_body_size 100M; # Adjust as needed for uploads
client_body_timeout 60s;
client_header_timeout 60s;
send_timeout 60s;
keepalive_timeout 65s;

Worker Processes and Connections

Tune Nginx worker processes and connections based on your server’s CPU cores and available memory. A common starting point is to set worker_processes to the number of CPU cores.

worker_processes auto; # Or set to number of CPU cores
worker_connections 4096; # Adjust based on system limits and expected load

SSL/TLS Optimization

Implement modern SSL/TLS configurations for security and performance. Enable HTTP/2 for multiplexing and header compression. Consider OCSP stapling for faster certificate validation.

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; # Consider security implications if enabled
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s; # Use your preferred DNS resolvers
resolver_timeout 5s;

# Enable HTTP/2
listen 443 ssl http2;

Gunicorn/PHP-FPM Tuning for WooCommerce

The application server layer is critical for dynamic content generation. For Python-based applications (like Django/Flask often used with WooCommerce integrations), Gunicorn is a common choice. For PHP-based WooCommerce, PHP-FPM is the standard. Tuning these involves managing worker processes, memory, and request handling.

Gunicorn Configuration

Gunicorn’s performance is heavily influenced by its worker type and count. For I/O-bound applications like WooCommerce, the gevent or event worker classes are generally preferred over the default sync. The number of workers should be calculated based on available CPU cores and memory, considering that each worker consumes resources.

A common starting point for Gunicorn workers is (2 * number_of_cores) + 1. However, for I/O-bound tasks, you might need more workers if they spend significant time waiting for external resources (like database queries or API calls).

# Example Gunicorn command line or configuration file
# Using event worker for better concurrency
gunicorn --workers 4 --worker-class gevent --bind 0.0.0.0:8000 myapp.wsgi:application
# Or using a configuration file (gunicorn_config.py)
# workers = 4
# worker_class = 'gevent'
# bind = '0.0.0.0:8000'

Monitor Gunicorn’s worker processes and their memory usage. If workers are consistently high in memory, it might indicate a memory leak or inefficient code. Adjusting --threads (if using a threaded worker class) or --worker-connections (for gevent/event) can also impact concurrency.

PHP-FPM Configuration

PHP-FPM pools are the core of PHP application serving. Tuning involves setting the correct process manager (dynamic, static, or ondemand) and the number of child processes.

For high-traffic sites, dynamic or static are usually preferred. dynamic scales based on load, while static pre-forks a fixed number of processes. The pm.max_children directive is crucial. A common formula is (total_server_memory / average_child_process_memory). However, it’s safer to start lower and monitor.

; Example php-fpm pool configuration (www.conf)
[www]
user = www-data
group = www-data
listen = /run/php/php7.4-fpm.sock ; Or a TCP socket

; Process Manager Settings
pm = dynamic
pm.max_children = 50       ; Adjust based on memory and load
pm.start_servers = 5       ; Number of children to start when the pool starts
pm.min_spare_servers = 2   ; Minimum number of idle respawned processes
pm.max_spare_servers = 10  ; Maximum number of idle respawned processes
pm.max_requests = 500      ; Max requests per child process before respawning

; Other important settings
request_terminate_timeout = 60s ; Timeout for script execution
; memory_limit = 256M ; Adjust based on WooCommerce's needs
; max_execution_time = 60 ; Adjust as needed

Monitor the number of active and idle PHP-FPM processes. If pm.max_children is consistently reached, requests will be queued or rejected. If memory usage is too high, reduce pm.max_children and potentially memory_limit.

DynamoDB Tuning for WooCommerce Data

DynamoDB, as a NoSQL database, requires a different tuning approach. The primary focus is on provisioned throughput (Read Capacity Units – RCUs and Write Capacity Units – WCUs) and efficient data modeling. For WooCommerce, common use cases include storing product catalogs, order data, customer information, and session data.

Provisioned Throughput Management

DynamoDB offers two modes: Provisioned and On-Demand. For predictable workloads, Provisioned throughput is cost-effective. For highly variable workloads, On-Demand can be simpler but potentially more expensive. For a high-traffic WooCommerce site, a hybrid approach or carefully managed Provisioned throughput is often best.

Key Strategy: Auto Scaling

AWS Auto Scaling for DynamoDB is essential. Configure it to adjust RCUs and WCUs based on actual consumption. Set target utilization percentages (e.g., 70% for reads, 70% for writes) to ensure sufficient capacity without over-provisioning.

Example Auto Scaling configuration for a WooCommerce product table:

Table: WooCommerceProducts

{
    "ScalableTarget": {
        "MaxCapacityUnits": 1000,
        "MinCapacityUnits": 50,
        "ResourceId": "table/WooCommerceProducts",
        "RoleArn": "arn:aws:iam::123456789012:role/DynamoDBAutoScalingRole",
        "ScalableDimension": "dynamodb:table:ReadCapacityUnits",
        "ServiceNamespace": "dynamodb"
    },
    "ScalingPolicy": {
        "PolicyName": "ReadCapacityScalingPolicy",
        "PolicyType": "TargetTrackingScaling",
        "TargetTrackingScalingPolicyConfiguration": {
            "TargetValue": 0.7,
            "PredefinedMetricSpecification": {
                "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
            }
        }
    }
}
// Repeat for WriteCapacityUnits

Data Modeling for Performance

DynamoDB’s performance is intrinsically linked to its data model. For WooCommerce, consider the access patterns:

• Product Catalog: Use a single table design with a composite primary key (e.g., PK: PRODUCT#<product_id>, SK: METADATA for product details, SK: ATTRIBUTE#<attribute_name> for attributes, SK: REVIEW#<review_id> for reviews). Use Global Secondary Indexes (GSIs) for querying by category, brand, or search terms.
• Orders: A common pattern is PK: CUSTOMER#<customer_id>, SK: ORDER#<order_id>. A GSI could be PK: ORDER#<order_id>, SK: ITEM#<item_id> for retrieving order items efficiently. Another GSI might be needed for querying orders by status or date range.
• Sessions: A simple table with PK: SESSION#<session_id> and TTL enabled is efficient.

Avoid patterns that require full table scans. Design your primary keys and GSIs to directly support your most frequent and critical queries.

Query Optimization and Indexing

When querying DynamoDB, always use Query operations with specific key conditions rather than Scan operations, which are inefficient and consume significant RCUs. Ensure your GSIs are designed to cover your query needs.

# Example using boto3 for querying products by category
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('WooCommerceProducts')

response = table.query(
    IndexName='CategoryIndex', # Assuming a GSI named CategoryIndex
    KeyConditionExpression=boto3.dynamodb.conditions.Key('CategorySK').eq('Electronics') # Assuming CategorySK is the partition key of the GSI
)

items = response['Items']

Regularly review your DynamoDB access patterns and CloudWatch metrics. Look for throttled requests, high consumed RCUs/WCUs, and inefficient queries. Adjust provisioned throughput or data models as necessary.