High-Traffic WordPress on a Dedicated Server: PHP-FPM, Redis, and MySQL Tuning That Actually Works

WordPress is famously easy to run and famously easy to run badly. On shared hosting, a site that does a few thousand page views a day can already feel slow. On a dedicated server, the same WordPress install can serve millions of page views a month — but only if the stack around it is tuned. The hardware is rarely the bottleneck; PHP-FPM pool sizing, opcache, object caching, and MySQL configuration are where the real performance lives. This guide covers the exact settings and hardware baselines that turn a dedicated box into a genuinely fast WordPress host.

Before you tune anything, make sure the server itself is sized for the traffic you actually have. A dedicated server gives you exclusive CPU cores, RAM, and NVMe storage — no noisy neighbors. If you are comparing plans, our comparison table lists the CPU, RAM, and storage specs side by side so you can match hardware to expected traffic.

Step 1: Size the Hardware Honestly

Traffic Level	CPU	RAM	Storage	Network
Small blog / brochure site	4 cores (Xeon E-2324G / i5-class)	16 GB	500 GB NVMe	1 Gbps
Medium business / WooCommerce	6–8 cores (Xeon E-2388G / Ryzen 7)	32 GB	1 TB NVMe	1 Gbps
High-traffic news / membership	8–12 cores (Xeon Silver / Ryzen 9)	64 GB	2 TB NVMe (RAID1)	1–10 Gbps
Multi-site / agency host	12–16 cores (dual Xeon / EPYC)	128 GB	2x NVMe RAID1 + SATA backup	10 Gbps

The rule of thumb: RAM is what you buy first (it feeds MySQL, Redis, and PHP), NVMe is non-negotiable for database and uploads, and CPU cores map almost linearly to concurrent PHP-FPM workers.

Step 2: Tune PHP-FPM (The #1 Bottleneck)

Each PHP-FPM worker uses roughly 60–120 MB of RAM. A 32 GB server with 24 GB usable should therefore run no more than ~200 workers. With pm = dynamic, set pm.max_children to the number of CPU cores × 4–6, not to the RAM ceiling — PHP workers are CPU-bound once caching is working. A typical pool config for a 6-core / 32 GB server:

pm = dynamic
pm.max_children = 30
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 500
request_terminate_timeout = 60

Also set opcache.enable=1, opcache.memory_consumption=256, and opcache.max_accelerated_files=20000 in php.ini. Opcache alone typically cuts PHP response time by 40–60% on WordPress because the whole core is recompiled on every request otherwise.

Step 3: Object Cache — Redis, Not Transients in the DB

Without an object cache, WordPress stores every option, transient, and fragment in MySQL. A high-traffic site can generate hundreds of duplicate queries per second. Redis with the Redis Object Cache plugin moves that into memory: hit ratios above 90% are normal, and query load on MySQL drops by an order of magnitude. Allocate 1–2 GB of Redis per ~1 million monthly page views; 4–8 GB covers almost any single site. Use a Unix socket (or 127.0.0.1) so cache traffic never leaves the machine.

Step 4: MySQL / MariaDB Settings That Matter

The single most important MySQL setting is innodb_buffer_pool_size: set it to 60–70% of available RAM (e.g., 20 GB on a 32 GB server). That keeps the entire working set of the database in memory. Other high-impact settings:

[mysqld]
innodb_buffer_pool_size = 20G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 200
key_buffer_size = 64M

innodb_flush_log_at_trx_commit = 2 is the standard speed/durability tradeoff for web workloads (1 is safer but ~5x slower on writes). With NVMe, O_DIRECT avoids double-buffering. If MySQL is still the bottleneck after this, enable the slow query log and look for missing indexes — most WordPress slow queries are a missing index on wp_postmeta or wp_options.

Step 5: Full-Page Caching — Nginx FastCGI Cache or Varnish

For anonymous visitors, serving a cached HTML page instead of running PHP changes time-to-first-byte from ~150–300 ms to 5–15 ms and lets one server absorb 10x the traffic. Nginx FastCGI cache is the simplest option — cache 200 responses for 60–120 seconds, purge on post publish/update via the WordPress REST API or a cache plugin:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=wpcache:100m max_size=5g inactive=60m;
fastcgi_cache wpcache;
fastcgi_cache_valid 200 60s;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

Logged-in users and WooCommerce cart pages must bypass the cache — match on cookies and skip the cache when wordpress_logged_in_ is present. With page caching + Redis + tuned PHP-FPM, a 6-core dedicated server comfortably handles peak traffic that would melt a shared-hosting account, and stays responsive under load spikes.

If you would rather not assemble and tune all of this yourself, a provider that gives you full root access to a dedicated box is the prerequisite — you cannot tune PHP-FPM or MySQL on shared hosting. InterServer’s dedicated servers include full root, NVMe storage options, and no per-visitor metering. Check current InterServer dedicated configurations to see what a 32 GB NVMe build costs.

The difference between a slow WordPress site and a fast one is rarely the hardware you bought — it is whether you configured the software stack to use it. Sizing RAM first, enabling opcache, adding Redis, tuning MySQL’s buffer pool, and caching full pages will take a mediocre dedicated server and make it outperform a bigger, untuned one. Once you know your traffic targets, see the full specs and pricing and pick a plan with headroom for the cache layers above.