How to choose CPU, RAM, and disk

Choosing CPU, RAM, and disk means sizing each resource around the real bottleneck on your site, not picking the biggest number on a comparison table. Cores help when many requests run at once. RAM holds PHP workers and database cache. Fast NVMe disk keeps both from waiting on slow reads. A simple brochure site often runs well on modest CPU. A busy shop with object cache usually needs more RAM before it needs more cores.

vmstat 1 10; free -h; df -h

Run those commands during a normal busy period, not during a plugin update. vmstat 1 10 gives ten one-second snapshots of run queue, idle time, I/O wait, and steal. free -h shows whether the system is already swapping. df -h shows disk capacity, which is rarely why wp-admin feels slow. Export about twenty minutes of usage from a typical busy window. If the CPU sits idle while workers are maxed out, you are limited by workers or locks, not by core count.

What CPU, RAM, and disk each buy you

Plan roughly 64–128 MB of RAM per PHP worker. InnoDB needs room so hot indexes stay in memory. Redis object cache usually wants a few hundred MB if you use it. Raising pm.max_children while starving MySQL is a common mistake, because more PHP processes then wait on the same small buffer pool. On shared hosting you get cPanel, LiteSpeed, and CloudLinux LVE without root access, so cPanel Metrics covers the same conversation without SSH. LVE limits show up there. If spikes only appear during xmlrpc traffic, disable xmlrpc. If they appear during checkout, a VPS with root is the next step to discuss.

NVMe helps wp-admin because random I/O stops queuing. Extra terabytes of capacity do not speed PHP. Disk space is for logs, backups, and staging copies, not for making the CMS faster. A small WordPress install in a large allocation is normal. Filling that space with mail and leftover cpmove files is also common, and a bigger disk alone will not make pages load quicker.

How many cores you actually need

More cores do not fix time to first byte by themselves. After TLS, TTFB is usually PHP, the database, or a cache miss. Extra cores on a lock-heavy plugin simply wait in parallel. Unmetered transfer on shared hosting is not the same as a high-speed dedicated NIC, so do not treat bandwidth like a compute spec. If you chose a metered plan, transfer limits are listed on the product page.

When you open a ticket, send vmstat output, free -h, and whether LSCache is enabled. Those three details stop a lot of guesswork. A clear support ticket with that information helps more than a screenshot of a sales comparison.

A simple order of decisions

Start with RAM if workers or MySQL are under pressure and the CPU is not saturated. Add CPU when concurrency is real and processes are ready to run, not blocked on locks or disk. Prefer NVMe performance over unused capacity when admin screens or queries feel sluggish. On VPS plans you get KVM with root in New York, London, Frankfurt, Singapore, Tel Aviv, or Tokyo. Dedicated servers add a physical chassis and IPMI when you outgrow shared limits. Renewal pricing stays the same, and hosting and VPS include a 30-day money-back window if the fit is wrong.