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.
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.
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.
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.
Did you find this article useful? Or do you use Simple:Press today? If so, please support Simple:Press with a review on WordPress.org. Every review goes a long way towards bringing other users on board!
More From Simple:Press
WordPress 5.9 is the gift that keeps on giving… This time around we’ve had to patch the drag-and-drop JS component in it to make it compatible. Upgrade to Simple:Press 6.6.6 to get the fix. The update should be in your WordPress automatic updates page. We’ve tested the fix with WP 5.8 and 5.9 but not…Read More
WordPress 5.9 introduced a new type of theme – the Full Site Editing theme where all components of the theme (including headers and footers) are blocks. This is a radical change to WordPress themes. But, the good news for Simple:Press is that we can still work with these new themes with a couple of minor…Read More
Simple:Press forums 6.6.x was released a few months ago and since then we have pushed a number of minor releases to tweak some things. These are the changes that were made: 6.6.3 Tweak Add a new overlay to the default 2020 theme to match the WP 2021 theme. The new overlay is the default on…Read More