July 20 2019

Excessive CPU consumption on SiteGround? Here is a case study on Magento shopping.

An example of a valid alternative to SiteGround.

Magento Slow Snail Banner

We want to document with this article the story of a "fairly well-known" seller of ecological diapers online that he generates about 20 thousand unique visitors per month it's about 300 thousand page views per month.

In short, from a purely systemic point of view, traffic is not high in any way, although more than adequate at an entrepreneurial level to generate important profits.

However, the old hoster had important navigation performance problems that in some cases made the website absolutely unsavable with related timeout errors and bad gateways.

Un 502 Bad Gateway on Magento it means that a timeout has been reached for waiting for an HTML response from the PHP interpreter running behind the NGINX webserver.


This can have multiple reasons, but essentially the main reason is that PHP is unable to complete the execution of its code and return an output to the Webserver.

502 bad gateway nginx
Typical 502 Bad Gateway NGINX error screen

Is the problem in the slowness of the code? Is the problem in the slowness of the car? An under-sizing of the hardware? An overselling of resources?

Essentially, all the reasons can be true, but certainly what interests an entrepreneur is not so much to understand what the cause is attributable to but that the website is online and generates sales, therefore profits, therefore profits.

Connecting to the old Hoster's cPanel control panel, the first thing we notice is the high peak of CPU consumption, which reaches almost 200% of the maximum allowed load.

Specifically, by checking the complete column below we see that this value is a value that has been practically exceeded for days, and that therefore the problem is not due to a spike (a peak) of visits, to some scans, to some bots or crawlers malicious, but simply an absolutely inadequate standard that compromises the normal browsing of potential customers and certainly also the crawling of content by search engines such as Google, thus penalizing also at the SEO level.

Specifically, we can read that in the last 24 hours, the CPU usage time is about 60000 against the 20000 allowed, which is exactly triple.

But what is running a Magento ecommerce like that to be so slow and so stingy on resources like the CPU?

One would have to ask several questions about it but "guessing" and taking into consideration very similar previous cases with the same supplier we thought it would be appropriate to vary hosting and migrate everything to our systems.

We therefore opted for a configuration on an Entry Level server equipped with Linux CentOS 7, which can ensure not only a prompt resolution of the load problem, but also an optimal execution speed, a triple backup, a resource monitoring system such as ZABBIX and a DDOS Layer 3 and Layer 7 protection.

The migration took place in various stages completed with the offline placement of the main site and the pointing of the DNS towards the new configuration, with an actual perceived down of about 5 minutes to make sure that the ecommerce did not go into split mode and therefore recorded payments and you order on both the old and the new hosting.

The server was equipped with Kernel 5.0 e BBR TCP to obtain network level improvements even for non-optimal 3G smartphone connections, an adequate MySQL tuning, http / 2 and various technical virtuosities that are part of our “secret recipe”.

CPU consumption after migration on our systems.

In the post migration of the site on our systems we decided to evaluate the CPU load to actually understand if there was an improvement of the whole and possibly intervene (if it was not enough) to a profiling with New Relic APM to understand in detail what was wrong at the application level.

As instead hypothesized in the initial phase, the problem was not application but rather at the level of hardware configuration and sizing.

In fact, the CPU load on the first day of hosting at our systems has never exceeded 10% even in the face of scheduled operations such as Database Backup and physical files.

Below you can see the load of the last 24 hours, or rather from 2:30 am when the Zabbix agent was installed to the time that the article was written.

Although it is not very clear for those who are not used to reading ZABBIX graphs, the green area represents the CPU time in idle time, i.e. not occupied and the blue line (difficult to see even with the naked eye) CPU consumption which according to the legend has an average value of 0,85% and a maximum value of 6%.

Why in the other hosting the CPU consumption was 60000 out of 20000 or an actual standard consumption of 300%?

Once again, it is not up to us to answer these questions, but only to demonstrate that the solution to load problems exist and we are usually one of the most popular solutions for entrepreneurs, SEOs and developers who decide to do profitable business online and not just keep online a slow and nerve-wracking site that does not bring any profit.

Having a Performant Magento Hosting means offering the customer the possibility of maximizing profits. There are no expenses, only investments.


Do you have doubts? Not sure where to start? Contact us

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


ManagedServer.it is the leading Italian provider of high performance hosting solutions. Our subscription model is affordable and predictable, so customers can access our reliable hosting technologies, dedicated servers and the cloud. ManagedServer.it also offers excellent support and consulting services on Hosting of the main Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Magento.

Scroll to Top