CloudPloy

High-Traffic WordPress and PHP Hosting on CloudPloy

A product launch, a viral post, a press mention - any of these can send your WordPress or PHP application from normal traffic to 10x or 100x in minutes. Without the right infrastructure, this turns into downtime, lost sales, and frustrated users. This guide explains how CloudPloy handles traffic at scale, what you need to configure before a spike hits, and how to diagnose problems when traffic surges.

Why WordPress Struggles Under High Traffic

Standard WordPress is not optimized for concurrent load. Every page request triggers a PHP process that:

  1. Bootstraps WordPress core (~100+ files loaded)
  2. Executes 20-40 database queries per page (more with plugins)
  3. Runs every active plugin hook and filter
  4. Generates dynamic HTML output

At low traffic this takes 200-500ms and is invisible to users. At high traffic, the database connection pool exhausts, PHP worker processes queue up waiting for slots, and response times climb to seconds - then requests start failing entirely.

The solution is to make the expensive parts happen rarely (or never) by adding caching layers between your application and the internet.

CloudPloy's High-Traffic Stack

CloudPloy deploys a multi-layer caching and scaling architecture for every application:

Layer Technology What it Handles
Edge Cloudflare CDN Static assets, cached HTML pages globally
Reverse Proxy Nginx + FastCGI Cache Full-page cache for anonymous visitors
Object Cache Redis WordPress object cache, sessions, transients
Application PHP-FPM in Docker Dynamic requests that bypass cache
Database MySQL with read replicas Queries that reach the database

A well-configured site on CloudPloy serves 95%+ of traffic from Nginx cache or CDN - PHP and MySQL are only involved for logged-in users, form submissions, and cart operations.

Part 1: Full-Page Caching with Nginx

Nginx FastCGI cache stores the complete HTML output of a page. When the next visitor requests the same URL, Nginx serves the cached response without touching PHP or MySQL. Response times drop to under 5ms.

CloudPloy configures Nginx page caching automatically for WordPress sites. The cache respects these bypass rules by default:

  • Logged-in users (WordPress auth cookies present) - always bypassed
  • WooCommerce cart and checkout pages - always bypassed
  • POST requests - always bypassed
  • URLs with query strings matching ?preview=, ?nocache= - bypassed
  • Everything else - cached for 1 hour (configurable)

To tune the cache TTL or add custom bypass rules, contact CloudPloy support or edit the Nginx configuration through your server's Advanced Settings.

Cache Invalidation on Publish

Cached pages become stale when you publish or update content. CloudPloy integrates with WordPress to automatically purge the relevant cache entries when you save a post, update a page, or approve a comment. Specifically:

  • Saving a post purges that post's URL, the homepage, any category/tag archive pages the post belongs to, and the sitemap
  • Updating site settings purges all cached pages
  • You can manually purge the full cache from App > Cache > Purge All in the CloudPloy dashboard

Part 2: Redis Object Cache

Even when full-page cache is bypassed (logged-in users, dynamic pages), WordPress still makes many redundant database queries within a single request. Redis object cache stores the results of these queries in memory and serves subsequent identical queries without hitting MySQL.

CloudPloy provides Redis as a managed service on every plan. To enable WordPress object caching:

  1. In your CloudPloy dashboard, go to App > Add-ons > Redis and click Enable
  2. Install the Redis Object Cache plugin in WordPress
  3. In WordPress admin, go to Settings > Redis and click Enable Object Cache
  4. Verify the status shows Connected

The Redis host and credentials are injected automatically as environment variables by CloudPloy - no manual configuration needed.

What Gets Cached in Redis

  • Database query results (post queries, option lookups, user queries)
  • WordPress transients (temporary data stored by plugins)
  • WooCommerce product and cart data
  • Navigation menus (expensive to generate)
  • Widget output

For a typical WooCommerce store, Redis object cache reduces database queries per request by 60-80%.

Part 3: Database Scaling with Read Replicas

Under heavy read traffic (product catalog browsing, blog archives), your MySQL primary server becomes the bottleneck. CloudPloy supports MySQL read replicas that handle SELECT queries while the primary handles only writes (INSERT, UPDATE, DELETE).

To add a read replica:

  1. Go to Server > Databases > Add Replica
  2. Choose the same region as your primary for lowest latency
  3. Select the replica size (typically the same as your primary)
  4. CloudPloy provisions and syncs the replica automatically

Configure WordPress to use the replica for reads by adding this to your wp-config.php (using the HyperDB plugin):

// wp-config.php additions for read replica
define('DB_HOST', getenv('DB_PRIMARY_HOST'));     // Primary for writes
define('DB_HOST_READ', getenv('DB_REPLICA_HOST')); // Replica for reads

Connection Pooling with ProxySQL

PHP-FPM creates a new database connection for every request. At 500 concurrent requests, that means 500 simultaneous MySQL connections - most databases start struggling above 200-300. CloudPloy can place ProxySQL between your application and MySQL to pool connections:

  • 500 PHP processes share a pool of 50 persistent MySQL connections
  • Query routing to primary/replica happens transparently
  • Slow query logging and connection statistics available in the dashboard

Enable ProxySQL under Server > Databases > Connection Pooling.

Part 4: CDN Configuration for WordPress

CloudPloy integrates with Cloudflare for CDN delivery. When properly configured, Cloudflare caches your full HTML pages at 300+ edge locations globally - a visitor in Tokyo gets your site served from Tokyo, not from your server in Frankfurt.

Recommended Cloudflare Settings

Setting Recommended Value Reason
SSL Mode Full (Strict) Encrypts all the way to your server
Caching Level Standard Respects cache headers from Nginx
Browser Cache TTL 4 hours Reduces repeat requests from same visitor
Rocket Loader Off Can break WordPress JavaScript
Minify (HTML/CSS/JS) Off Let WordPress plugins handle this
Under Attack Mode Off (enable manually during DDoS) Triggers browser challenge for all visitors

Excluding Dynamic URLs from CDN Cache

WooCommerce cart, checkout, and my-account pages must never be served from CDN cache. Create a Cloudflare Page Rule (or Cache Rule in the new interface) with these bypass conditions:

  • /cart* - Cache Level: Bypass
  • /checkout* - Cache Level: Bypass
  • /my-account* - Cache Level: Bypass
  • /wp-admin* - Cache Level: Bypass
  • /wp-login.php - Cache Level: Bypass

Part 5: Traffic Spike Preparation Checklist

Before a planned high-traffic event (product launch, sale, press feature), run through this checklist:

48 Hours Before

  • Upgrade your CloudPloy server to the next tier (it takes under 2 minutes, with no downtime)
  • Enable Redis object cache and verify it shows Connected
  • Test that Nginx page cache is working: run curl -I https://your-site.com/ and check for X-Cache: HIT on the second request
  • Enable Cloudflare's CDN if not already active
  • Disable any non-essential plugins (social share counters that make external API calls, etc.)
  • Test your checkout flow end-to-end (cache bypass must work correctly for cart/checkout)

24 Hours Before

  • Run a load test using a tool like k6 or Loader.io against your staging environment
  • Check your PHP-FPM worker count - each CloudPloy plan has a default configured for normal traffic; you may need to increase this for a spike
  • Pre-warm the cache by crawling your most important pages
  • Set up an uptime monitor (CloudPloy's built-in monitoring sends alerts if response time exceeds 2 seconds)
  • Note your database slow query threshold and review recent slow queries in the dashboard

Day Of

  • Enable Cloudflare's "I'm Under Attack" mode only as a last resort - it adds a 5-second delay for all new visitors
  • Keep the CloudPloy dashboard open to the Real-Time Metrics view
  • Monitor PHP-FPM queue depth - if it starts growing, traffic is exceeding your worker count
  • Watch database connection count in App > Metrics > Database
  • Have your CloudPloy support contact ready - Priority support has a 2-minute response SLA

Part 6: WooCommerce High-Traffic Considerations

WooCommerce requires special attention because a significant portion of its traffic bypasses full-page cache:

Reduce Cart Session Overhead

WooCommerce creates a session for every visitor who adds a product to their cart. At scale, this creates thousands of rows in the wp_options table (for PHP session storage) or Redis keys. Configure WooCommerce to use database sessions over native PHP sessions and set an aggressive session expiry:

// wp-config.php
define('WC_SESSION_EXPIRING', 3600);       // 1 hour
define('WC_SESSION_EXPIRATION', 7200);     // 2 hours absolute max

Disable Stock Check on Cart Page

By default, WooCommerce queries the database on every cart page load to verify stock levels. For high-volume shops, this adds a synchronous DB query to every logged-in page view. Move this check to checkout only:

// In functions.php
add_filter('woocommerce_check_cart_items', '__return_false');
// Note: stock is still validated at checkout - this just removes the cart-page check

Fragment Caching for Cart Widget

The mini-cart widget in your header shows cart contents and must be dynamic for logged-in users. The rest of your header can be cached. Use fragment caching to cache everything except the cart widget, keeping full-page cache effective even for logged-in visitors browsing non-cart pages.

Part 7: Monitoring During High Traffic

CloudPloy provides real-time metrics at App > Metrics. During a traffic event, watch these signals:

Metric Warning Threshold Action
PHP-FPM Queue Depth > 10 requests waiting Increase PHP-FPM workers or upgrade server
DB Connection Count > 80% of max_connections Enable ProxySQL connection pooling
Redis Memory Usage > 80% of allocated RAM Increase Redis memory or reduce object cache TTL
Cache Hit Rate < 70% Investigate what's bypassing cache
CPU Usage > 85% sustained Upgrade server tier or add read replica

Frequently Asked Questions

How much traffic can CloudPloy handle?

There is no hard limit. A properly cached WordPress site on a mid-tier CloudPloy server (4 vCPU, 8GB RAM) can handle tens of thousands of concurrent anonymous visitors because most requests are served by Nginx cache or CDN without touching PHP. Dynamic traffic (logged-in users, WooCommerce checkout) is limited by PHP-FPM worker count and database capacity - both can be scaled up within minutes from the dashboard.

Does CloudPloy support horizontal scaling (multiple servers)?

Yes. CloudPloy supports multi-server deployments where your application code runs on multiple servers behind a load balancer. For WordPress, this requires shared file storage for wp-content/uploads (CloudPloy provides NFS-backed shared volumes) and a shared Redis instance for object cache and sessions. Contact support to configure a multi-server deployment.

What happens if my site goes down during a traffic spike?

CloudPloy's health check monitor detects downtime within 30 seconds and restarts unhealthy containers automatically. If the issue is resource exhaustion, the automated restart will temporarily restore service. Contact CloudPloy support immediately if the automatic recovery does not resolve the issue - Priority support SLA is 2 minutes response time.

Can I load test my staging environment before go-live?

Yes, and you should. CloudPloy staging environments are isolated from production and accept load testing traffic. Use the staging environment URL from your dashboard. Note that staging servers are typically smaller than production, so scale your test results accordingly.

How do I handle a DDoS attack?

CloudPloy infrastructure sits behind Cloudflare, which provides automatic DDoS protection at the network layer. For application-level DDoS (legitimate-looking HTTP flood), enable Cloudflare's Under Attack Mode from your Cloudflare dashboard - this presents a browser challenge to all new visitors that bots cannot pass. Additionally, configure Cloudflare rate limiting rules for your most expensive endpoints (/wp-login.php, /xmlrpc.php, /wp-json/).

Planning a high-traffic event and want a pre-launch infrastructure review? Contact CloudPloy support - we'll review your caching configuration, run a load test analysis, and ensure your stack is ready before the traffic hits.