CPU core count and frequency

Both virtual machines and bare metal servers come in different shapes and sizes. When comparing one offering to another, we're typically looking at things like memory, disk size and CPU. Without looking into more detail, however, it's easy to make false assumptions, especially when such details are abstracted and hidden away.

In this lesson we're going to look at CPUs and some tricky terminology around them like cores, threads, virtual CPUs, frequencies and more, and how it all relates to running a WordPress application.

CPUs, cores, threads and frequency

A CPU, or processor, is a physical microchip plugged into the motherboard of a computer. While there are plenty of dual- and even quad-socket motherboards, most mass-market hosting offerings are centered around single-socket computers.

A CPU core is part of a CPU which does the actual processing. Modern-day CPUs typically have between 8 and 128 cores, allowing us to process data in parallel.

A CPU thread is a further extension of that, which allows one physical CPU core to act like two separate logical cores. For example, a 16-core processor with SMT (Hyper-Threading, etc.) will show 32 available cores in the operating system. This generally improves parallel processing even more.

The CPU frequency, or its clock speed, is the rate at which the CPU executes instructions. It's not a very useful metric when comparing CPUs across different families, generations and architectures, as it is not the only factor in determining performance.

Dedicated servers

When it comes to dedicated server specs, you'll usually know the exact model of the CPU in your server, which gives you the exact core count, frequency, whether multi-threading is available and other details. Even if the hosting provider doesn't publish these numbers, you can always look them up on the processor vendor's website.

While on a server, you can identify the CPU model, architecture, cache sizes, core count and various other things using the commands:

lscpu
lscpu -e
cat /proc/cpuinfo

Comparing processors is quite easy. I always use the cpubenchmark.net website for single-threaded and multi-threaded CPU comparison. The Geekbench processor benchmarks are also a useful resource.

Virtual machines

With VMs it's a lot muddier, and this is where the marketing departments absolutely love to do their dirty work. You can use the commands listed above and you'll be lucky to get some information. A lot of the time it'll be quite obfuscated.

Resource allocation with virtual machines is as flexible as it gets, and completely controlled by the provider. What this means is that whatever providers publish on their pricing page is basically meaningless.

Some will reference Cores, others will say Threads, some might say vCPUs, ECUs, CPU units, sometimes even outright CPUs. This is quite misleading, and they might as well call them carrots. However, these carrots give us two somewhat useful pieces of information:

• The number of carrots advertised is usually the number of logical CPUs we'll see in the guest OS
• 4 carrots is typically twice as fast as 2 carrots within the same vendor

Do note that some vendors will also have compute-optimized carrots, high-frequency carrots, and others. What this means is that we get more CPU allowance on the same number of carrots. This brings us to one of the most important performance factors when it comes to virtual machines.

CPU quota or allowance

If a CPU core is capable of performing X amount of work every second, an allowance or CPU quota of 50% will allow our virtual machine to perform only half of X every second. An allowance of 5% gives us only 1/20th of the full core capacity.

This is a very simplified explanation. In reality things often get a lot more complex, with variable allowances, throttling, baseline reservations, burst capacity and even CPU credit systems where your VM accumulates "credits" when it's idle, and can then "spend" these credits to use some CPU. The entire T-lineup on AWS (t2, t3, t4g instances) is built on such a system.

Some cloud and VM providers have a "dedicated CPU" offering, where they guarantee 100% allowance/quota for each listed core, usually at a significantly more expensive price. However, most common offerings are shared-CPU, meaning you get a small slice, and a slightly larger slice with "compute optimized" offerings.

The actual size of that slice is almost never publicized, as vendors want to retain the ability to change these without notice for rebalancing, cost optimization and more.

This makes it increasingly hard to compare an offering from one vendor to a similar offering from another vendor. Furthermore, provisioning a cloud instance is a bit of a lottery in itself too, as you may get extremely lucky and placed on a freshly deployed server with very low density and silent neighbors. Or you can get extremely unlucky, and end up on an old, soon-to-be decommissioned, oversubscribed, max-density server with a bunch of spammers.

Luckily, you can always run a Geekbench or an HTTP benchmark on two servers and find out which gives you better performance. You can find existing benchmarks online too for some overall guidance. Do note that synthetic benchmarks (Geekbench, PressMark) are directional, but nothing beats load testing an actual WordPress site to determine true performance.

CPUs for WordPress

There is no one-size-fits-all unfortunately. WordPress is a single-threaded application (a single request can only run on one core), and depending on the plugins, themes and overall configuration, can easily be CPU-bound or IO-bound, sometimes depending on the time of day.

It's a PHP application which typically runs behind a multi-threaded or multi-process manager, such as PHP-FPM. Combine that with Nginx and MySQL/MariaDB, and you can definitely make good use of multiple cores, but you don't want to sacrifice single-core performance too much.

A good rule of thumb is looking at the cache hit-rate. With 90% and more it's safe to sway toward more CPU cores for a higher worker count and concurrency. With low cache hit rates and highly dynamic sites, it's often more beneficial to invest in better single-core performance.