The Hidden Side of Accelerating Technologies – WordPress and the Lifehack.bg Issue
A while ago we faced an unusual case with the famous website Lifehack.bg and today we decided to tell you more about it.
In short, this is a story about a WordPress site having all accelerating and caching technologies activated but still not loading properly just a single product in WooCommerce in rush hours when the product is advertised.
Lifehack.bg displayed useful content but users often would not be able to access it. The problem occurred at moments when the website was advertised/a newsletter was sent out and it got a large number of visitors simultaneously.
The hosting service used by the website was Managed VPS – managed virtual server with a lot of resources. A single website was hosted on the server. The resources offered by the respective plan were more than enough to deal with about 120,000 unique visits per month. However, the resources seemed insufficient for handling the website’s most important moments as the site was completely running out of server resource.
The customer was amazed how server with considerable resources could not handle the website visitors in rush hours as the service performed far worse from the expected results. This certainly raised doubts over our service quality as worries did not seem groundless at all given the website and server’s performance.
From a customer point of view it seemed impossible for the problem to arise from the website's CMS, especially given the fact that the website was using minimum external plugins as well as one of the most common caching plugins – wp-rocket.
Searching for Solution
After the first complaints from the customer on the website’s interruptions in rush hours we found out that the reason for that was high server load which was exhausting the server resources: RAM, PHP processes, CPU resource and everything else. Following the domino effect, all resources were just getting exhausted one by one.
We first tried to fix the issue in rush hours by activating the SuperCache* web accelerator in cPanel. SuperCache caches the source code of a page as this includes both static and dynamic content. Unlike Memcached or Redis which work on application level, SuperCache* is operating in front of the real server where the website is hosted.
When activating SuperCache we also upgraded the server to 2.4 which allowed us to enable HTTP/2 for the website.
These actions certainly contributed to speeding up the website but there were still interruptions in rush hours.
So we continued our quest to discovering what was impeding the website’s proper operation as we made a few more changes to SuperCache’s configuration. This considerably increased SuperCache’s performance as more than 75% of the requests were already served from cache (compared to 10% before our changes).
Unfortunately, speeding up cached webpages did not change the website’s overall performance and its internal WordPress processes in any way. The issues stayed the same and in case more users visited the website simultaneously it just went down. The problem with peak server overloading and website interruption kept occurring.
We were very unhappy to see that our efforts did not lead to a successful solution of the problem. Moreover, our customer was not satisfied and could not do their job properly because we had not yet found a solution for the issue.
Once cached, the webpage starts loading with the speed of an HTML page as the acceleration might be measured in times.
We will tell you more about the capabilities of SuperCache in our next articles. Follow our blog!
Changing the Direction
So we decided to change the direction and take a dive deep into WordPress despite the case going beyond the hosting service offered.
Lifehack.bg voted us complete trust.
We performed detailed examination of the system and website’s performance, the settings, plugins, themes and everything else that might have caused the issue. We went far beyond the hosting service, closer to the development side.
We made a copy of the real website so as not to interfere its current operation.
During the troubleshooting, we performed numerous tests and we encountered something very bizarre: it occurred that wp-rocket only manages to cache a tiny part of the website. Knowing that wp-rocket is a paid and renowned caching plugin we did not expect to discover an issue there.
But in fact that was the very reason for the server slow loading and website interruption. For an unknown reason wp-rocket did not manage to cache a big part of the website's content which was probably due to an incompatibility with some of the WordPress or WooCommerce settings.
Caching plays considerable part of a website's optimization, performance and resource usage. When a website with a big number of visitors does not manage to effectively use caching technologies, this results in considerably slower speed and increased server resources usage.
After we replaced wp-rocket with W3 Total Cache and made sure it ran smoothly, the website's performance changed a lot.
Replacing the plugin together with the other changes we made so far resulted in better performance and optimized server usage.
After our customer tested the website's optimized version, all changes were transferred to the real website.
The issue with rush hours vanished into thin air!
Here is a short list of the major changes we made:
- We deactivated wp-rocket.
- We installed, activated and configured W3 Total Cache.
- We upgraded PHP to 7.1.
- We activated opcode caching through Opcache in PHP.
- We enabled Redis instance in cPanel after which we configured W3TC to keep the cached objects in the RAM using Redis.
- We set up browser caching in W3TC.
- We integrated W3 Total Cache with SuperCache so that SuperCache automatically purges cache when the website gets modified.
Comparative data and results from WordPress optimization
The described changes led to multiple improvements in different aspects of the website's performance:
- Over 30 times decrease of CPU usage when already cached URLs are processed.
- 3 times decrease of CPU usage for URLs receiving the first hit (e.g. which are not cached up to now).
- Prior optimizing, each of the website's pages executed between 150 and 200 queries to the database. After optimizing, the average value decreased significantly and now varies between 50 and 80.
SQL queries before optimizing:
SQL queries after optimizing:
- The time for loading separate pages was also considerably reduced as the time for loading the Home page was 9 seconds and now is 2.2 seconds when there is no browser cache. With browser cache the loading time went down to 0.5 seconds.
Loading time for home page before optimizing:
Loading time for home page after optimizing:
Loading time for a category page before optimizing:
Loading time for a category page after optimizing:
- Last, but not least: the CPU time went down almost three times. In other words, CPU usage for loading the website is reduced by three times.
Communication is the key for success.
We help our customers not because we have to, but because of our desire to be satisfied, the positive energy we get from their gratitude and the urge to keep working the same way.
It is true that sometimes we face limitations because of the specific features of the hosting industry we work in, but we do have knowledge and expertise. Cases getting us out of our comfort zone make us more capable and increase our professional knowledge. We get even more ready to face the next challenge.
What we learned from this case
WordPress is a great CMS for creating and managing websites which allows us to use a variety of plugins and tools.
But when it comes to optimizing and acceleration we have to be very careful. No matter what we decide to change aiming to optimize (installing a plugin or changing settings) we always have to test so as to make sure changes influence positively the website's performance.
Very often tiny details such as a setting or a plugin may drastically change our website's speed.
The easiest solution for fixing performance issues is buying additional server resources. But this is a way to cure symptoms, not the real cause for the disease.
Optimizing a website, when possible, is a more effective and long-term solution.