WordPress at Scale: 100k+ Requests/Min on a Single Server (Guide)

WordPress powers over 40% of the internet, but its reputation for poor scalability persists. Out-of-the-box, a default WordPress installation can handle a few hundred requests per second before collapsing under database load. But with the right tuning, it’s possible to serve 100,000+ requests per minute (1,600+ requests/sec) on a single modern dedicated server in 2025.

This guide walks through a real-world WordPress performance tuning playbook: from selecting hardware to configuring caching, optimizing PHP-FPM and MySQL/MariaDB, and benchmarking results. The focus is on squeezing every ounce of performance from a single node before considering horizontal scaling.

🔹 Hardware Selection

Scaling starts with choosing the right foundation. Recommended 2025 specs for 100k+ req/min:

CPU: AMD EPYC 9754 (192 cores) or Intel Xeon Platinum (Sapphire Rapids). Even 32–64 dedicated cores suffice.
RAM: 64–128 GB DDR5 ECC.
Storage: NVMe Gen4 SSDs (3–5 GB/s throughput). RAID-10 for redundancy.
Networking: 10G NIC minimum, 25–100G preferred in DC environments.

Tip: Avoid VPS with shared CPU for high-scale WordPress. Go bare metal or high-performance dedicated VPS with pinned vCPUs.

🔹 Web Server: Nginx vs Apache

Apache’s process-based model struggles under high concurrency. Nginx’s event-driven architecture scales far better.

Recommended Nginx Config Snippet:

worker_processes auto;
worker_connections 65535;
multi_accept on;
use epoll;

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 30;
    types_hash_max_size 4096;

    gzip on;
    gzip_types text/plain text/css application/json application/javascript application/xml;
}

This allows 50k+ concurrent connections with proper kernel tuning.

🔹 PHP-FPM Tuning

Default PHP-FPM settings are conservative. Key parameters:

[www]
pm = static
pm.max_children = 256
pm.max_requests = 500
request_terminate_timeout = 30s

Adjust pm.max_children based on available RAM. Each PHP process consumes ~30–60 MB under load.

🔹 Database Optimization (MariaDB/MySQL)

The database is the most common bottleneck. Recommended settings (my.cnf):

[mysqld]
innodb_buffer_pool_size = 32G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 2000
query_cache_type = 0

Key idea: Fit entire working dataset into innodb_buffer_pool_size. Use slow query logs to optimize queries.

🔹 Object Caching (Redis)

WordPress repeatedly queries the DB for the same options, posts, and meta. Redis object cache reduces DB load by 80%.

sudo apt install redis-server
wp plugin install redis-cache --activate
wp redis enable

Set persistent Redis connections in wp-config.php:

define('WP_REDIS_CLIENT', 'phpredis');
define('WP_REDIS_MAXTTL', 900);

🔹 Page Caching (Nginx + FastCGI Cache)

For anonymous users, full-page caching eliminates PHP/MySQL from the request path. Example Nginx snippet:

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:500m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 301 302 1h;
}

With FastCGI caching, cache hit requests can serve in 1–2 ms.

🔹 Kernel and System Tuning

At scale, OS-level tuning matters:

# /etc/sysctl.conf
fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1

Apply with sysctl -p. Also raise ulimit -n 65535 for Nginx/PHP-FPM.

🔹 CDN Integration

A CDN (Cloudflare, Fastly) handles static assets (CSS, JS, images), offloading 70–90% of requests. The origin server only handles dynamic PHP requests, drastically reducing load.

🔹 Benchmark Results

We benchmarked a tuned WordPress setup (Nginx + PHP-FPM + MariaDB + Redis + FastCGI cache) on a 64-core EPYC server with 128 GB RAM and NVMe SSDs.

Test	Requests/sec	Latency (p99)
Without cache	1,800	180 ms
With Redis object cache	5,400	60 ms
With full-page cache	16,800	5 ms
With CDN (90% offload)	100k+ per minute sustained	~2 ms

Observation: Proper caching turns WordPress from sluggish to lightning fast, capable of handling enterprise-scale traffic on a single server.

🔹 Security and Reliability

Enable fail2ban for brute force protection.
Use UFW/iptables to limit access to DB ports.
Automate backups with rsync or rclone.
Monitor with Zabbix/Grafana to detect anomalies early.

✅ Conclusion

Scaling WordPress to 100k+ requests per minute on a single server is absolutely achievable in 2025. The key strategies are:

Use high-performance hardware (dedicated CPU, NVMe, 10G NIC).
Switch to Nginx with FastCGI caching.
Enable Redis object cache + persistent connections.
Optimize MariaDB with proper buffer pool sizing.
Tune PHP-FPM and kernel parameters.
Leverage a CDN to offload static traffic.

At WeHaveServers.com, we provide optimized WordPress VPS and dedicated hosting in Romania/EU, pre-tuned with Nginx, Redis, and MariaDB for maximum performance.

❓ FAQ

Can WordPress really handle 100k+ requests per minute?

Yes. With caching and tuning, WordPress can scale to millions of pageviews/day on a single optimized server.

Do I need a CDN for scaling?

Strictly speaking, no — but it helps. A CDN drastically reduces origin load and improves global performance.

Is Redis mandatory?

No, but Redis reduces database queries significantly. It’s highly recommended for scale.

Does WooCommerce scale the same way?

WooCommerce is heavier due to cart/session logic. You’ll need object caching, optimized queries, and possibly database clustering.

Is bare metal required for scaling WordPress?

Not always, but bare metal ensures predictable CPU and I/O performance. Shared VPS may introduce jitter.