Load Testing Your WordPress User Sync:
Benchmarks for 10K+ User Databases

Scaling a WordPress user sync system is one of those engineering challenges that feels straightforward until you are actually doing it. At 500 users, sync is fast, reliable, and entirely invisible. The queue processes events within seconds. API calls complete cleanly. Sub-sites update in real time. Everything works. At 50,000 users during a promotional campaign that drives 3,000 new registrations in an hour, the queue that was invisible at 500 users becomes the most critical piece of infrastructure you own — and if you have not tested it at that scale before the campaign launches, you will be discovering its limits in production, in real time, with real users waiting for access.

Load testing user sync is not the same as load testing a website. A website load test measures how many concurrent requests your server can handle before response times degrade. A user sync load test measures something more complex: how the entire pipeline from event creation through queue processing through API delivery behaves under sustained high throughput, and whether the configuration is tuned to maintain acceptable latency and data freshness even when the user database is in the tens or hundreds of thousands.

This guide provides the methodology, benchmarks, and optimization playbook for load testing WordPress multi-site user sync at high-volume scale. It covers what to measure, how to simulate realistic load, what the numbers mean, and which configuration levers produce the biggest improvements when performance falls short of acceptable thresholds.

This guide is written for developers and system administrators managing WordPress networks with large or rapidly growing user bases. It assumes comfort with WordPress server configuration and basic familiarity with database and HTTP concepts. Where terminal commands are provided, they are for Linux/Ubuntu environments, which covers the vast majority of WordPress hosting configurations.

The five performance metrics that define sync health at scale

Before you can load test a sync system, you need to know what you are measuring. Generic server metrics — CPU utilization, memory usage, HTTP response times — are necessary but not sufficient for understanding sync performance. These five sync-specific metrics tell you whether your sync pipeline can sustain the throughput your user base demands.

Load testing methodology: simulating realistic sync scenarios

Realistic load testing for user sync requires simulating two distinct scenarios: the Bulk Push scenario (a large number of user records being pushed at once) and the sustained registration scenario (a continuous stream of new user events over an extended period). Each scenario stresses different parts of the sync pipeline and reveals different bottlenecks.

# Create 10,000 test users on master site
for i in $(seq 1 10000); do
  wp user create 
    testuser${i} 
    test${i}@loadtest.invalid 
    --role=customer 
    --user_pass=testpass123 
    --allow-root
done

# Verify count
wp user list --role=customer --format=count --allow-root

# Register 1 user every 36 seconds (100/hour) for 1 hour
for i in $(seq 1 100); do
  wp user create 
    campaignuser${i} 
    campaign${i}@loadtest.invalid 
    --role=customer 
    --user_pass=testpass123 
    --allow-root
  sleep 36
done

# Monitor queue depth every 5 minutes in parallel
while true; do
  echo "$(date): $(wp --allow-root eval 
    'echo count(get_option("nus_queue", []));')"
  sleep 300
done

Benchmark reference: expected performance at different user database scales

These benchmark ranges reflect realistic performance on managed WordPress hosting (e.g., WP Engine, Kinsta, Cloudways) with standard MySQL configurations. Performance on shared hosting will be significantly lower. Performance on dedicated servers with optimized MySQL configurations can exceed these ranges.

* At 100K+ users, database optimization (covered below) becomes critical. Without index optimization, these numbers degrade significantly. The ranges shown assume wp_usermeta is properly indexed.

Queue monitoring during load testing in Nexu User Sync – WordPress high-volume user sync queue with load testing visibility for 10K+ user databases — monitor queue depth and throughput in real time to identify performance bottlenecks during load tests.

The four bottleneck locations and how to diagnose each one

When a load test reveals that your sync system is not meeting the performance benchmarks, the cause is almost always one of four bottleneck locations. Each produces different symptoms, and each requires a different fix. Identifying which bottleneck is limiting throughput before applying optimization avoids wasted effort on the wrong layer.

# Check WordPress cron event schedule
wp cron event list --allow-root

# Check if system cron is set up
crontab -l | grep wp-cron

# Time a manual queue processing cycle
time wp --allow-root eval '
  do_action("nus_process_queue");
'

# Check how many events were processed
# (compare queue depth before and after)

# Enable slow query log temporarily (in MySQL)
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.1;
SET GLOBAL slow_query_log_file = '/tmp/mysql-slow.log';

# Check index coverage on wp_usermeta
SHOW INDEX FROM wp_usermeta;

# Check count and table size
SELECT COUNT(*) FROM wp_usermeta;
SELECT
  table_name,
  ROUND(data_length/1024/1024, 2) AS data_mb,
  ROUND(index_length/1024/1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_name = 'wp_usermeta';

# Time a direct REST API call to the sub-site
time curl -X POST 
  https://subsite.example.com/wp-json/nus/v1/receive 
  -H "Authorization: Bearer YOUR_TEST_KEY" 
  -H "Content-Type: application/json" 
  -d '{"test": true}' 
  --silent --output /dev/null

Database optimization for wp_usermeta at scale

At large user counts, the wp_usermeta table becomes the dominant performance factor in user sync operations. A site with 100,000 users and 50 meta fields per user has 5 million rows in this table. Without proper indexing, queries that read or write to this table for specific users and meta keys perform full table scans, which become prohibitively slow as the table grows.

-- Check existing indexes
SHOW INDEX FROM wp_usermeta;

-- WordPress adds these by default:
-- PRIMARY KEY (umeta_id)
-- INDEX user_id (user_id)
-- INDEX meta_key (meta_key(191))

-- Add composite index if missing (critical for sync performance)
ALTER TABLE wp_usermeta
  ADD INDEX user_id_meta_key (user_id, meta_key(100));

-- Verify the index is being used for a typical sync query
EXPLAIN SELECT meta_value
FROM wp_usermeta
WHERE user_id = 12345
  AND meta_key IN (
    'billing_first_name',
    'billing_email',
    'affwp_referral_affiliate'
  );

The EXPLAIN output for the query above should show key: user_id_meta_key and a rows estimate in the dozens, not the millions. If it shows a full table scan (type: ALL), the index is not being used and needs to be added or the query needs to be restructured.

Beyond indexing, two additional database-level optimizations matter at large scale. First, periodically purge autoloaded user meta that is no longer needed — the autoload column affects WordPress object cache loading behavior and bloated autoloaded meta slows down every page request, not just sync operations. Second, consider enabling MySQL’s query cache (deprecated in MySQL 8.0 but available via ProxySQL or application-level caching) for read-heavy meta queries, which can dramatically reduce database load when the same meta values are read frequently during batch processing.

Event logs in Nexu User Sync – WordPress high-volume sync event log for load testing analysis and throughput benchmarking — use event timestamps to calculate actual delivery latency and identify processing delays during load tests.

Load test checklist: before your next traffic spike

Run through this checklist before any event, campaign launch, or product release that is expected to drive a significant registration spike. Each item takes minutes to verify and collectively ensures your sync infrastructure will not become a bottleneck at the moment it matters most.

The difference between a sync system that scales confidently to 100,000 users and one that collapses at 10,000 is rarely the sync plugin itself. It is almost always the infrastructure configuration surrounding it — cron frequency, batch size, database indexing, and sub-site performance. These are solvable engineering problems with known solutions. Load testing before you need the capacity is what converts them from surprises into known parameters.

Nexu User Sync’s WordPress high-volume user sync queue with configurable batch processing is designed to perform at scale when the surrounding infrastructure is correctly configured. The queue panel gives you the visibility to measure throughput during load tests, the batch size setting lets you tune processing capacity to your hosting environment, and the event log provides the timestamps you need to calculate delivery latency and identify where in the pipeline time is being lost.

Configurable Batch Size · System Cron Compatible · Queue Depth Visibility · Event Log Benchmarking

Know your sync capacity before you need it. Test at scale. Tune with precision.

Nexu User Sync’s configurable queue, system cron compatibility, real-time depth monitoring, and event log give you everything you need to load test, benchmark, and tune performance for user databases at any scale.

Nexu User Sync by NEXU WP

WordPress plugin · Configurable Queue · System Cron · Bulk Push · Performance Monitoring

Get Nexu User Sync