A few days ago we moved our site from Liquid Web to our new FireupWP and WPCloudDeploy project platform. This new platform allows us to use dedicated cloud VMs from places like Digital Ocean, Linode and Vultr. We pay the cost of the VMs with no markup which provides huge savings over regular hosts.
We moved from an 8-core virtual machine running on an Intel Xeon E5-2620v4 (2.1 / 3.0 Ghz) to a 2-core Dedicated High Frequency VM with 4 GB of RAM at Linode.
Yes, you read that right. From eight cores to two cores.
Even we were surprised by the results.
Initially the drastic reduction in cores was only going to be our starting point and we fully planned to scale up the server to at least 4 cores. But we quickly realized that 2 dedicated cores was more than enough.
Check out this chart:
That’s the CPU usage as reported by Linode within the first few hours of the move.
The first part of the chart with all the large spikes is when we were importing the site, doing a ton of backups and such. After that, the cpu usage fell to below 100% (200% is the highest level since there are 2 CPUs). The average CPU load is about 30%.
By our own subjective measures, performance was far far better that what we were dealing with before – the Linode CPU chart just served to confirm our impressions.
Tweaks
So, of course you’re asking, what kind of tweaks did we apply?
The short answer is – not much at all. Really.
We still have our proxy service and we’re still using the same caching plugin that we always used (instead of the WPCloudDeploy nginx cache). The improvement in performance is almost all because we’re running the thing on a dedicated VM with dedicated cores.
We thought that the cpu cores were some sort of high-frequency cores but when we checked they were running around 2Ghz. (We suspect that if we moved the server to Vultr’s High Frequency cores, performance would be even better.)
We used the default WPCloudDeploy stack which is a standard, well-known and tuned WP LEMP stack, turned on the so-called “6G” fire wall to filter out some bad traffic at the Nginx web server level and boom – certain long-running website tasks that sometimes took 20 seconds were now taking 5 seconds.
Metrics
We ran some brute-force performance tests to see what it would take to make the server fall over. It turns out that the number of users that the server can comfortably handle is in the hundreds. You can read more about the results of these tests on fireupwp.com.
Bottom Line
Our home page (and most other pages) should load a lot faster now for users that aren’t logged in.
As we continue optimization – mostly working on our proxy service to stop bot traffic before it hits the server, performance should continue to get incrementally better! And, if we move to PHP 7.4 from 7.2, we’ll likely get some more incremental performance benefits as well.