WordPress performance: Database proxy strategies for high concurrency

When my team hit a wall with a high-traffic e-commerce build, we realized that standard object caching wasn't enough to stop the database from choking. Even with a perfectly tuned Redis instance, the sheer volume of concurrent requests during a flash sale meant our MySQL primary was constantly hitting its connection limit.

We needed to shift our perspective on WordPress performance and rethink how we handle data retrieval at the infrastructure level. Instead of relying solely on the application layer, we decided to implement a database proxy to intercept queries and enforce a strict read-through caching strategy.

Why standard object caching failed us

Initially, we relied heavily on WordPress object caching optimization: A guide for senior engineers to reduce query load. It worked for standard page views, but during spikes, the "cache stampede" problem became impossible to ignore. When a key expired, dozens of PHP processes would simultaneously try to regenerate the same expensive database query.

We tried increasing our wp_cache TTLs, but that led to stale data issues that were notoriously difficult to debug. We also experimented with WordPress performance through granular Redis object cache tagging, which helped with invalidation, but the database was still doing the heavy lifting during cold starts. We needed a solution that lived between the application and the database.

Architecting a read-through proxy layer

To solve this, we moved away from the application-side wp_cache_get logic and implemented a proxy layer using ProxySQL. By placing this between our PHP-FPM workers and the MySQL cluster, we could enforce read-through caching at the network level.

Here is the basic architecture:

1. Application Layer: WordPress sends queries to the ProxySQL port (6033).
2. Proxy Layer: ProxySQL checks its internal memory cache.
3. Cache Hit: If the result exists, ProxySQL returns it instantly, completely bypassing the database.
4. Cache Miss: ProxySQL forwards the query to the read-replica, then caches the result before returning it to WordPress.

This approach is significantly more efficient than standard WordPress Performance: Implementing Redis Persistent Object Caching because the database doesn't even see the request.

Configuring the ProxySQL Read-Through Pattern

You don't need to rewrite your WordPress core. You just need to configure your query_rules in ProxySQL to identify high-cost read operations. Here is a simplified example of how we route and cache read-heavy SELECT statements:

SQL
-- Create a rule to cache specific high-traffic queries
INSERT INTO mysql_query_rules (rule_id, active, digest, cache_ttl, apply)
VALUES (10, 1, '0x1234567890abcdef...', 300, 1);

-- Load the rules into runtime
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

The digest is the hashed version of your SQL statement. By setting a cache_ttl of 300 seconds, we effectively eliminated about 40% of the traffic hitting our read replicas during peak periods.

Dealing with the trade-offs

This isn't a silver bullet. The biggest challenge with a database proxy is cache invalidation. When you update a post or a product, the proxy doesn't automatically know that the cached result is stale. We had to write a small helper plugin that triggers a PURGE command to the ProxySQL interface whenever a specific post_id is updated.

Additionally, this architecture requires careful monitoring of memory usage on the proxy host. If you cache too many unique queries, you'll overflow the buffer and see a performance cliff. We started with a modest 512MB cache buffer and tuned it up based on Stats_Cache_Hits vs Stats_Cache_Misses metrics.

Scaling for the future

If you're dealing with massive high-concurrency scaling issues, you might also consider WordPress Database Optimization: Implementing HyperDB for Scaling alongside your proxy layer. While the proxy handles the read-through logic, HyperDB can help you distribute writes across multiple masters.

Honestly, I’m still experimenting with the balance between application-level caching and proxy-level caching. There's a risk of "double-caching," where you store the same data in Redis and again in the proxy memory, wasting resources. For now, I've restricted proxy caching to only the most expensive, read-heavy queries, leaving the standard object cache to handle the rest of the application state. It’s a messy, manual tuning process, but it’s the only way to keep a database from falling over when the traffic hits.