Understanding PHP workload and the impact of CPU
Too many heavy plugins, inadequate server hardware and too many sites on "cheap shared hostings" are among main reasons why you often see laggy Wordpress sites and (too) long checkouts on Magento. In this post we'll present some of our findinds regarding the impact that a server processor (CPU) has on page loading speed.
- a small number of high-frequency cores or (often 4-8 cores / ~3.0-5.0 GHz)
- a bigger number of lower-frequency cores (often 10+ cores / ~2.0-3.5 GHz).
What is PHP workload like (in simplified terms)?
How do CPU specs impact common webhosting?
1. PHP is a single-threaded process so CPU's single-thread performance has a significant impact on PHP execution time. In other words: PHP really likes HIGH FREQUENCY CPUs. Why is this an issue? Common webhosting CPUs are often high core count, low-frequency (slower) and that makes them poorly suitable for PHP apps. It is very unlikely you will get a fast PHP CPU unless you order it specifically (often comes with premium price).
2. On the other hand a webserver service (e.g. NGINX, Apache) that is actually responding to web requests prefers the number of cores to their frequency as serving concurrent users is a multi threaded task. That is why looking only at the CPU frequency to solve webhosting problems is not enough.
3. Serving static files or cached content (with some cache-ing plugin or NGINX cache) often means that a webserver can return a reply WITHOUT even asking PHP for processing the request. That is why cached content is very fast, is almost never an issue and basicaly any CPU will do.
4. Content like webshop cart, admin area, personalized or closed content for registered users, custom pricing, POS invoicing can rarely be fully cached and require PHP processing. Imagine serving back an invoice you did for another client and serve it to all future visitors until cache expires. These are tasks where PHP processing is required and where it really shows up what kind of a "PHP worker" you have at your disposal.
5. It's good to remember that on average you only have 2-4sec to show the page or your user is gone.
Which parts of page loading speed can a faster CPU improve and which ones it can not
Faster CPU can decrease the time of processing un-cached pages. So its biggets impact is on the initial part right after the user clicks your link - TTFB (Time to first byte) or even more precisely on a "server response time". It makes the site feel more "snappy" as the lag after clicks is shorter.
Faster CPU does not have a meaningful impact on:
- Part of TTFB related to the distance between the user and your server (e.g. user in Europe, server in US)
- CPU speed has a negliable impact on serving fully cached pages.
Impact of virtualization and shared hosting on CPU performance
- Virtualization has a negative effect on most if not all tasks (CPU, disk, network, latency...). Many times I've seen webposts that stated that the impact on modern CPU performance to be ~5%. But that is probably based on an average of many different tests. In our testings with PHPBench benchmarking test the loss was ~15%. And that was in a form of LXC (Linux Containers) which is one of the lightest forms of virtualizations. We tried privileged LXC status, tested on 3 generations of Intel CPUs, with CPU mitigation disabled and enabled, on multiple different servers and all set to performance mode. PHPBench showed significantly lower scores in containers than on base metal installations. So if you are on a VPS or any other kind of a virtualized hosting, this is the immediate negative impact.
- If you are not on a dedicated server, then you are in some form on shared hosting which means there is almost 0% chance that the CPU is idle at the moment you receive a PHP request to process. That means that you'll never get CPU "turbo speeds" due to its architecture and constant parallel load of other sites on the same server. The most realistic case for analysis is to use CPU's base frequency which is quite a bit lower that turbo.
- Then there is the negative impact of "noisy neighbours. If you are on a budget, cheaper hosting, it's a very high probability that the hosting provider is "overprovisioning" the server as much as possible. That means that performance is bound not just to CPU base clocks, but also the queue your requests are in for processing (imagine 50-100 websites on a same server getting their requests in-line for processing. A line you can not skip).
How to recognize the lack of PHP processing power
I found this comment from one user on a site dedicated to webshosting reviews (https://researchasahobby.com/ram-cpu-shared-hosting-plans/):
On my cPanel the CPU usages goes upt to 70-99%.
In other words: as long as a webserver is returning cached pages it works fast. But as soon as something needs to be done (in real time), it takes ages for the server to prepare a response. This is a great case about 2 typical examples of mostly un-cacheable content: webshop and admin pages.
This case is by no means the only one with symptoms like this.
How to troubleshoot a case suspecting a lack of CPU power
Situation in the case above could be due to:
- Unoptimized code (plugins, content),
- CPU being to slow or
- server being to busy doing other tasks (e.g. overprovisoned too much).
CASE 1: If you put a copy of this website on a solid dedicated server and it's too slow, then part of the issue is the code. You are facing a decission whether to change/remove slow plugins or get a hosting with faster CPU and see how fast will it run there. After you eliminate issues with code optimization, there is still a chance that your webhosting is not good enough (CASE 2).
CASE 2: If a page on a test server works fine, then think about changing the hosting provider or getting a better hosting package. Performance will often go along these options:
Shared > VPS > Dedicated > Private Cloud
If your webpage is running on PHP, then CPU has quite an impact on the performance you can get. But if you need to remember just one thing: For webpage speeds and user experience CPU frequency/speed often matters more than cores.