You're comparing two plans side by side: one with 8 cores at 2.4 GHz, the other with 4 cores at 3.8 GHz. Both have 32 GB of RAM. The price difference isn't small either. The problem is that neither of these numbers alone tells you how your site will behave under heavy load. Server specifications should be read based on the work that will actually run on it, not based on the biggest number in the table.
Cores vs. Frequency: Which One Determines Web Load
For typical web workloads (PHP-FPM, Node, relational databases), single-core frequency is usually more important than core count, as long as the number of cores isn't less than the number of concurrent workers. A PHP request almost always finishes on a single core; parallelism happens between requests, not within a single request. So if you have 4 cores at 3.8 GHz and your load is 20 concurrent requests, the cores will queue up, and higher frequency will respond to each request faster.
Conversely, if you're running Elasticsearch or an image processing queue on that same server, the story changes. Those workloads are truly multi-threaded, and 16 cores at 2.4 GHz beats 4 cores at 3.8 GHz. This is where people make mistakes: someone moves a WordPress site to a 32-core machine with a 2.0 GHz base frequency and then says "the server got stronger but the site got slower." The reason is that MySQL works single-threaded, and that one thread now runs slower.
A practical number: if you open top and see %Cpu(s) at 100 percent but load average is only 1.2, you have a frequency problem, not a capacity problem. If load is above 8 on 4 cores but each core is at 40 percent usage, it's an I/O problem. The difference between these two states changes the entire purchasing decision, and it's laid out step by step in the guide to diagnosing high server load.
ECC and CPU Generation: Specifications You Won't See in the Sales Table
What ECC Actually Changes
ECC corrects single-bit memory errors and detects double-bit errors. On a typical web server, the probability of such an error occurring over a year is low. But on a machine running ZFS or staying up for months without a restart, the absence of ECC means a flipped bit can make its way into data written to disk and corrupt the checksum too. If you use ZFS or Ceph, consider ECC non-negotiable. If it's a simple VPS for a corporate site, the extra money you'd spend on ECC is better spent on NVMe.
Processor Generation and What You Don't See in Benchmarks
An old-generation Xeon with 16 cores can beat a new-generation 8-core processor in multi-threaded benchmarks while being slower in practice. The reason is twofold: lower IPC, and support for newer instructions like AVX-512 that some cryptography and vector processing libraries use. For TLS, newer processors have better AES-NI, and this directly affects the number of handshakes per second.
A quick way to assess: before buying, if you can test, run this and compare the number with your current plan.
openssl speed -evp aes-256-gcm
sysbench cpu --threads=4 --time=30 runThe output of openssl speed gives you a number like aes-256-gcm 1.2 GB/s. If the new plan doesn't double this number, it's probably not worth upgrading for encrypted workloads.
RAM, Disk, and Bandwidth: Three Numbers That Lie to Each Other
| Specification | The Number You See in the Store | The Number That Actually Matters |
|---|---|---|
| RAM | 32 GB | Free RAM at peak hours, and swap rate |
| Disk | 500 GB SSD | Random IOPS and queue depth |
| Bandwidth | 10 TB per month | 1 Gbps port vs. 10 Gbps |
Don't check RAM with free -h; check it with vmstat 1. If the si and so columns show anything other than zero, you're short on RAM, and no amount of PHP-FPM tuning will fix that. A server with 16 GB of RAM and zero swap is faster than a 32 GB server that's constantly swapping.
On disk, the capacity number is almost meaningless. What determines database load is random IOPS. An NVMe on PCIe 4.0 can deliver over 500,000 random 4K IOPS; a SATA SSD stays under 100,000 in the same test. If MySQL is on a SATA disk and iostat -x 1 shows %util at 100 while await is above 20 milliseconds, the bottleneck is the disk, not the CPU. For transferring data between two servers at this stage, transferring files with scp and rsync is the fastest way without intermediaries.
Virtual vs. Dedicated: Where the Wrong Choice Gets Made
A dedicated server is the right choice when you either need ECC and full core control, or your load has consistently exceeded the capacity of a virtual machine. If you only spike occasionally, virtualization is better because it shares resources. But here's a point that's rarely mentioned: on a virtual machine, "8 cores" means 8 vCPUs that may sit on 4 physical cores. If neighbors are heavy users, you'll see steal time.
Check the st column in top. If it's above 5 percent, the problem isn't your code. Measure this number several times during peak hours; if it's consistently high, it's time to change plans or migrate to a dedicated server. For workloads with high fluctuation where you want to scale resources up and down, a cloud server offers more flexibility, and you don't have to pay a fixed cost for a year for a three-hour peak.
If you're just getting started and aren't yet sure how much load there will be, starting with Linux hosting and measuring actual consumption is more sensible than buying a big machine based on guesswork.
Frequently Asked Questions
How many cores are enough for a high-traffic WordPress site?
Usually 4 cores with high frequency is enough, provided caching is configured correctly. The bottleneck for most WordPress sites isn't CPU; it's the number of unindexed queries and the lack of object caching. Before upgrading, measure the number of queries per page.
If CPU is still saturated after full caching, then upgrading makes sense. Until that point, the extra money you spend on cores is wasted.
Is NVMe really faster than SATA SSD, or is it marketing?
Under database load, the difference is real and measurable. NVMe works over the PCIe interface and supports deeper queues; this makes it several times faster than SATA in random IOPS. For a static site you won't feel the difference; for MySQL with heavy writes, it's night and day.
How do I tell if I'm short on RAM or short on CPU?
If vmstat 1 shows non-zero numbers in the si and so columns, it's a RAM problem. If those two columns are zero but load average exceeds the number of cores and %Cpu(s) stays above 80 percent, it's a CPU problem.
Also consider a third state: both numbers are normal but the site is slow. Then the bottleneck is the network or disk, and you should check iostat and TTFB separately.
Is ECC necessary for a web server?
For a typical web server, no; for anything running ZFS, Ceph, or software storage, yes. If you have to choose between more RAM and ECC RAM and your workload isn't a file server, go with more RAM.
Before any decision, record a week of actual consumption on your current server with sar or vmstat. Buying based on a table number is the most expensive way to learn this lesson. ServerNet's technical documentation in the knowledge base was written for exactly these measurements, and if you're still unsure after reading the numbers, the ServerNet blog has examined real-world load examples.