WordPress Kubernetes Performance: Scaling with HPA and Redis

During our last Black Friday promotion, our primary WordPress site hit a wall. We saw CPU utilization on our PHP-FPM pods spike to 92%, causing request latency to balloon from a stable 250ms to nearly 4 seconds. It wasn’t just a simple traffic surge; the database was getting hammered by redundant queries that should have been cached. We were running a standard monolithic deployment on EKS, and our lack of granular scaling was killing us.

WordPress Kubernetes Performance and Scaling

If you’re running WordPress Kubernetes workloads, you’ve likely realized that scaling is rarely as simple as adding more replicas. PHP-FPM is stateful regarding its configuration, but stateless regarding the application logic. The real bottleneck usually hides in the database round-trips.

We first tried to solve the latency issue by simply bumping up the replicas count in our deployment manifest. It failed. Adding more pods just increased the connection pool pressure on our RDS instance, which was already at its IOPS limit. We needed a smarter approach that combined Horizontal Pod Autoscaling with an effective caching layer.

Implementing Redis Object Cache

To stop the database from choking, we moved our object caching to an external Redis cluster. We used the Redis Object Cache plugin in WordPress, ensuring it connected to a managed Elasticache instance rather than a local sidecar.

PHP
#6A9955">// wp-config.php configuration
define('WP_REDIS_HOST', 'redis-cluster.internal.example.com');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);

By offloading session data and transient objects to Redis, we saw our average database query volume drop by roughly 65%. This was the single most effective WordPress performance optimization we performed. Once the database was stable, we could finally look at the pod-level scaling.

Kubernetes HPA WordPress Strategy

With the database pressure relieved, we implemented Kubernetes HPA WordPress rules based on custom metrics. We didn't use standard CPU thresholds because PHP-FPM often spikes during startup; instead, we targeted requests-per-second (RPS) using the Prometheus Adapter.

YAML
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: wordpress-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: wordpress
  minReplicas: 3
  maxReplicas: 15
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 50

This setup worked well, but it introduced a new "cold start" problem. When the HPA scaled up, new pods took around 28 seconds to initialize and register with the load balancer. We mitigated this by setting readinessProbes that actually checked for the Redis connection before allowing traffic. If you're struggling with network-level overhead, you might also consider Implementing Kubernetes NodeLocal DNSCache for Lower DNS Latency, as we found that DNS lookups were adding a consistent 15-20ms penalty on every new pod scale-out event.

Lessons Learned and Trade-offs

The transition wasn't seamless. We initially tried to use a local Redis container within the pod to minimize latency, but it caused massive memory fragmentation when multiple pods scaled simultaneously. We abandoned that for the managed service.

If you’re managing your own nodes, remember that scaling pods is only half the battle. If your cluster runs out of capacity, your HPA won't do anything. We eventually integrated Kubernetes Autoscaling with Karpenter and AWS Spot Instances to ensure that when the HPA requested more pods, the cluster actually had the underlying compute to host them.

I'm still not entirely happy with our current cooldown periods. We’re seeing "flapping" where the HPA scales up and down too rapidly during minor traffic fluctuations. Next, I’m planning to tune the behavior field in the HPA spec to implement a more aggressive scale-up and a lazier scale-down, but I’m worried about the cost implications during off-peak hours. It’s a constant tug-of-war between availability and your monthly cloud bill.

FAQ

Why use Redis instead of Memcached for WordPress? Redis supports persistence and more complex data structures, which makes it more resilient if the cache service restarts.

Does HPA work with the default WordPress image? Yes, but you need to ensure your persistent storage (like EFS) is configured correctly so that all pods share the same media assets, or you'll see broken images across your scaling events.

Is Redis Object Cache enough for high-traffic sites? It helps, but you should also implement a full-page cache (like Varnish or a CDN like Cloudflare) to prevent the request from hitting PHP entirely whenever possible.