Help me speed up HostingDiscussion' WordPress-based news site

Before anything, I would like to thank ⭐ @SharedGrid ⭐ for the colossal investigative effort. All of what I am about to post is the result of Daniel's work, and nearly all of the words come from his messages to me.

After all of the work done to date, we started by looking at WHM, Apache, MySQL and PHP configuration of my VPS, particularly focusing on the performance of the machine itself. We immediately noticed a pretty high CPU usage, at times reaching 100%, most likely during a busier browsing activity. Daniel associated it with a couple of reasons:

1) the CPU clock speed is low at around ~2.1Ghz, WordPress is very much a single threaded bit of software so it’s taking longer for processes to complete their task and exit the CPU. A VPS with less cores but a higher clock speed (Ghz) is more beneficial than more cores and less speed. 2) Apache, MySQL, PHP has no performance optimization which can contribute to high CPU usage.

The VPS is running a default version of MySQL 5.7, which went end of life in October 2023. While initial recommendation was to switch to MariaDB, for now, we just performed optimization.

The Apache configuration was default as cPanel ships it, which is very conservative out of the box. We performed optimization on ServerLimits and RequestWorkers.

We also performed OS and Kernel optimizations for better memory and process handling.

We switched php-cgi to php-fpm, as it's much superior in the way it handles PHP requests.

We updated php.ini settings to better suit WordPress.

These 5 improvements led to a dramatic decrease in server load, so the changes have definitely made a difference. The new averages at the moment were: 1.40, 1.08, 1.14 - whereas they were near between 3-4 before, 4 being the limit.

Query Monitor, installed to see how the site was performing in terms of queries to the database, was now showing that queries were completing in less than 0.1s which is excellent, but the page generation time was still varying between 5-7 seconds. There was also the issue of the other 2 columns taking longer to load in compared to the first.

To be continued.
 
@SharedGrid continued investigation showed that we were hitting the performance limit of the CPU:

I have poked and prodded WordPress and Query Monitor to see what’s going on, the database queries are running very fast every single time at under 0.1s so although upgrading the database to MariaDB would improve performance, I don’t think we would actually see that much difference since I made the optimisation changes on MySQL to make enough of a noticeable difference in loading speed.

The problem we have is the ‘page generation speed’ which we've seen as low as 4 seconds and as high as 8 seconds depending on how many users are present on the forum and news site.

The page generation speed takes into account the amount of time to complete the 1) required database queries, 2) the amount of HTTP calls, 3) any blockers (bad coding), 4) WordPress plugins and 5) how long it takes for the server to serve the page to the browser. We can rule out 1) since queries are completing under 0.1s, 2) and 3) can be ruled out as Query Monitor is reporting nothing abnormal with those, 4) is fine as Code Profiler shows which plugins are slowing down a site, nothing reported… which leaves us with 5).

As a rule of thumb with slow WordPress sites, if services are fully optimised and the both 4 points are ruled out as not causing an issue then it comes down to the hardware. I touched on this previously, but I believe the slow clock speed of 2.1Ghz is causing the issue - While loading the page & viewing ’top’ on the server at the same time, I can see the PHP process hit 100% of 1 CPU core and return back to a normal CPU % again once the page has loaded in my browser. WordPress & PHP are effectively single threaded, meaning a request can only use 1 CPU core at a time; the lower the clock speed, the longer it takes a process to complete it’s CPU processing time which is where we’re seeing the slow down. The higher the clock speed, the quicker the process exits the CPU and the web page is served to the user.

Daniel from SharedGrid is a fan of Litespeed (it offers the quickest TTFB and page loading speed for WordPress) as he brought it up a few times in this thread. Well, he gave it a try on our server and it didn't make a difference at all. This backed up the evidence that it's down to server hardware as we're at the absolute maximum it can perform.

These two screenshots of the optimizations he worked on show the before and after results. The real showstopper here is the huge boost in database performance.

Before
Screenshot 2024-08-11 at 21.46.10.png

After
Screenshot 2024-08-11 at 21.46.31.png



Personally, and without any exaggeration, that was one of the most interesting experiences and reads I've had in a long time, primarily of the way Daniel broke things down, eliminating issues one by one, finally narrowing down to the culprit in a totally scientific way. I asked for permission to copy some of the information from his emails, because I wanted everyone to see the work that he's done.

Stay tuned for more.
 
HostingDiscussion.com will be closed as of this Friday, August 16, 2024, 9:00AM EST for improvements.
 
There are indeed several key factors to consider when optimizing the speed of a WordPress site, and many of the suggestions you may have come across are quite common.

One effective approach is switching to LiteSpeed, a web server that significantly outperforms Apache in many scenarios. LiteSpeed offers enhanced performance, built-in caching, and better handling of high-traffic websites. We’d be happy to offer you a free trial on our LiteSpeed-powered servers, allowing you to directly compare it against your current Apache setup and see the potential improvements. (I see this has been already suggested and tried - but I am just dumping knowledge)

Additionally, enabling compression, such as GZIP or Brotli, can help reduce file sizes and speed up load times. If your site is content-heavy, optimizing images is crucial. Tools like ImageOptim, TinyPNG, or even built-in WordPress plugins can compress images without sacrificing quality. Also, consider how your images are served – if they’re hosted on the same server as your website, they might be contributing to the load. Offloading static assets (like images) to a Content Delivery Network (CDN) could distribute the load more efficiently and reduce latency by serving content from a location closer to the user.

Lastly, don’t overlook other performance tweaks like minimizing CSS/JavaScript, leveraging browser caching, and ensuring your database is well-optimized. By addressing these aspects, you can significantly enhance your site's performance.

If you'd like to chat further, feel free to drop me a message.

- Liam
 
One effective approach is switching to LiteSpeed, a web server that significantly outperforms Apache in many scenarios.
I had a little peek into what's it like to run HD's WordPress news site on LiteSpeed and it was killing it. 🚀 'Page generation time’ down to something like 1.6s, which is a massive improvement compared to the 4-8s we were seeing before. And that is prior to Litespeed caching enabled, so we can expect even better performance. 🤞

And thank you for the kind gesture, Liam.
 
We switched php-cgi to php-fpm, as it's much superior in the way it handles PHP requests.
I wouldn't be surprised if this was a _huge_ portion of your TTFB cost. I love some classic CGI for simplicity, but performant it is typically not.
 
What a great effort all around to improve things and a phenomenal outcome. The page loading time is perfect. How interesting that these are the speeds from a UK-based server. I am almost curious what it would be like from a US location.
 
Back
Top