Skip to main content

VPS Setup Criteria

Choosing the right Virtual Private Server (VPS) sets the performance ceiling for your WordPress stack. Instead of picking a plan by marketing tier, size CPU, RAM, and storage based on how much of your traffic can be served from cache and how much must be computed dynamically (checkout, logged-in pages, admin, and AJAX).

Quick Summary

Underpowered hardware makes slow TTFB and instability likely no matter how well you configure WordPress. Prefer predictable CPU performance (non-burstable or at least non-throttled under load), NVMe storage, and enough RAM headroom to avoid swapping and OOM events.

Rule-of-Thumb Target Formulas​

Estimate Concurrent Dynamic Processing​

Determine the maximum concurrent execution requirement: Concurrency = Peak Dynamic RPS * Average Server Payload Execution (seconds)

Mathematical Example: If your WooCommerce cart evaluates at 12 requests per second (RPS) and PHP takes 0.25s to compute the cart, you demand 3 concurrent processing threads simultaneously.

Map Concurrency into vCPU Requirements​

  • Static Cache-Heavy Sites: vCPU = max(2, Concurrency)
  • Dynamic Database-Heavy Sites: vCPU = max(4, Concurrency * 1.5) (The 1.5 multiplier serves as the buffer for background Cron and Stripe webhooks.)

Size RAM (Heuristic)​

Calculate your memory boundaries rigidly before deployment:

memory-allocation-baseline.txt
Base OS + Kernel Services : 0.7 - 1.0 GB
Web Server Core (LSAPI)   : 0.3 - 0.8 GB
PHP-FPM Worker Pool       : 0.12 - 0.22 GB (Dynamic sites pull to the extreme high end)
OPcache Memory            : 0.12 - 0.25 GB
MariaDB (InnoDB buffer)   : 25% - 50% of total physical RAM
Redis Object Dataset      : Raw database footprint + 20% memory overhead
Emergency Headroom        : Minimum 20% of total physical RAM remaining

Component Evaluation Criteria​

Processor (vCPU) Parameters​

Mandatory Requirements:

  • Single-Thread Density: PHP is traditionally single-threaded; higher clock speeds often reduce PHP latency more than adding many slow cores.
  • Dedicated Architecture: Absolute avoidance of AWS T-Series or DigitalOcean 'Premium' burstable credits. Dynamic eCommerce requires 100% fair-share CPU time 24/7.
  • Low Steal-Time Thresholds: Cloud providers aggressively oversell nodes. Use top to verify st (steal time) sits securely at 0-1%.

NVMe Storage Parameters​

Mandatory Requirements:

  • PCIe NVMe: Pure Generation 4 NVMe; SATA SSDs are a bottleneck for database writes.
  • Random IOPS: Prioritize random 4k read/write Input/Output Operations Per Second over raw sequential MB/s speed blocks.
  • Capacity Limits: Size the disk to hold the database, access logs, and core files, while mandating 50% remaining free space specifically for SSD wear-leveling algorithms.

Provisioning Verification Checks​

Immediately after the VPS spins up, execute these terminal checks:

warning

The fio test can generate significant I/O load. Avoid running it on production during peak traffic (and don't run it on any disk where you can't tolerate performance impact).

vps-hardware-verification.sh
# Confirm vCPU geometry and threading
lscpu

# Verify active memory pools
free -h

# Map block storage mounting structures
lsblk -o NAME,MODEL,SIZE,TYPE,MOUNTPOINT

# Test absolute low-level origin latency (requires ioping)
ioping -c 10 /

# Execute violent I/O test simulation (Avoid on live production blocks)
fio --name=randread --iodepth=16 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=30 --group_reporting --filename=/var/tmp/fio.test

Strategy Side-by-Side Application​

Content sites survive almost entirely via Layer 9 Caching and Cloudflare Edge interception. The hardware pressure remains incredibly low.

Application TierTarget TrafficvCPU AllocationRAMStorage Structure
StartupMinimal caching baseline1-2 Cores1-2 GB20 GB NVMe
Growth Engine100,000 monthly visits2-4 Cores4-6 GB40-80 GB NVMe
Pro Scale500,000 monthly visits4-6 Cores8-12 GB80-160 GB NVMe

Operating heavily from edge caching implies the server only computes data intermittently when the cache naturally expires or clears during publishing.

The 60-Second Provisioning Decision​

  1. Classify: Identify pure static delivery or dynamic computation.
  2. Formula: Extract peak sustained concurrency.
  3. vCPU Calculation: max(4, 1.5 * concurrency) for storefronts.
  4. Memory Accumulation: Stack PHP + DB + Redis + OPcache + 30% Headroom.
  5. Disk Selection: Reject HDD/SSD; demand PCIe NVMe arrays.
  6. Virtualization Strategy: Enforce KVM nodes and terminate anything advertising "Burstable Credits".

Common Mistakes & Troubleshooting​

Engineering FailureAnalytical CauseCorrective Action
Massive CPU Steal > 5%The hosting provider severely oversold the physical rack hosting your VPS node.Migrate the stack instantly away from that provider or swap to bare-metal servers.
OOM (Out Of Memory) crashesOver-allocated memory settings starved the OS, causing the OOM killer to terminate PHP-FPM.Recalculate memory allocations and keep meaningful headroom (often ~20-30% depending on workload).
Hidden I/O throttlingBudget providers enforce hard limits on random IOPS, capping database reads/writes.Review the SLA for unthrottled IOPS and test disk performance after provisioning.
Provisioning "Many Slow Cores"Assigning 16 cores at 2.1 GHz to process an intensive WooCommerce script. PHP relies on single-thread speeds.Provision 8 cores at 3.5GHz+ instead of 16 slower cores.

What's Next​