RSS
down-arrow копия 3
justification-1
down-arrow-d

Solving Website Performance Issues in Shared Hosting Environments

One of the most difficult server issues to troubleshoot is performance degradation. For a website owner, it’s a challenge to find issues on their server, but for hosting providers the issue is magnified when performance affects thousands of customer servers and their websites.

Download the case study

  • Uniques Challenges for Hosting providers
  • Key Performance Issues Affecting Web Hosting Providers
  • Slow Plugins
  • Long Processing SQL Requests
  • Long Processing External Requests
  • Long Processing System Functions
  • Connections limit
  • PHP Issues
  • Mitigation

You probably know that performance degradation isn’t always the fault of the hoster’s server. Website owners install plugins and software that could affect performance, or they configure their sites in an unoptimized way that harms application performance.

web-plugin (1)

100% of websites use at least one Ads Plugins, Menu Plugins, Search, Search filtering, output buffering to replace http with https plugins

Website owners are often ill-equipped to identify the root cause, but even host administrators find performance troubleshooting difficult.

outdated (1)

Over 30% of PHP versions running on websites have reached their EOL

Performance issues can stem from a wide range of factors including hardware malfunction, third-party software, external API calls, poor configurations, or simply insufficient resources.

question

And one metric to be defined with your help:
How many of your customers have full time webmasters to maintain the performance of their website?

Unique and Comparable Challenges for Hosting Providers by Lucas Rolff, Founder of Hosting4Real

Hosting4Real is a hosting company based in the Netherlands targeting all customer segments from small and medium businesses to large enterprises. The far majority of their customers are businesses that either operate 100% online or use their online presence to generate even more sales. The audience is often the ones experiencing slowness on websites. Hosting4Real aims to provide fast web hosting on traffic-intensive sites even in a standard shared hosting environment.

Their main goal is to have a good product that customers enjoy and are satisfied with. As the organization grows, they also aim to help customers grow as their traffic needs grow.

left-quote

The web hosting industry is cut throat where pricing drives much of the industry, but customer service and performance are large factors in customer satisfaction. With hundreds of sites running on a shared single server, poor performance on a server affects dozens of customer sites. Any long-term performance issues could create a massive loss in customer revenue over a preventable situation.

Lucas Rolff

Founder of Hosting4Real

image001
logo-hosting4real-dark_-_Lucas_Rolff_(1)
location

LOCATION

Europe, Netherlands

target-audience

CUSTOMERS

Small, medium businesses that operates 100% online, large enterprises

database-storage

TYPE OF HOSTING SERVICES

Shared hosting, managed hosting, managed services (Hosted Redis, RabbitMQ and Elasticsearch), backup solutions and a content delivery network

linux

OPERATING SYSTEM

For shared hosting - CloudLinux OS Shared Pro, CloudLinux OS, or CentOS 7 with cPanel. For managed servers CDN is based on Ubuntu 18.04 or 20.04 CentOS 7, 8, Ubuntu 20.04, or Debian (Proxmox). Over time it will be completely switched all toCloudLinux OS Shared Pro and AlmaLinux.

target

BUSINESS GOAL

To provide a top-class service for customers with fast performance and a secure infrastructure

problem

BUSINESS NEEDS

Stability, performance, performance insights, and security

coronavirus (1)

With COVID-19 lockdowns, people are even more dependent on their online presence because in many countries, various sectors are either limited in what they can or cannot do, or outright closed. For those companies to survive this pandemic, they need to be able to deliver a product to customers so they stay online.

For anything e-commerce related, customers are often requesting fast and snappy sites - therefore Hosting4Real needs to offer good performance to all sites, which is why they opted for technologies such as CloudLinux, Imunify360, KernelCare, and LiteSpeed Web Server - they all help lower resources, increase stability and improve performance.

And obviously, with many sites being based on WordPress these days, site owners often require insight into what an application is actually doing. As a web host provider, Hosting4Real must spot performance bottlenecks and work those bottlenecks out with customers.

Key Performance Issues Affecting Web Hosting providers

left-quote-black

About 90% of MTTR goes to identifying the problem

AdobeStock_188695030

Key problems for enterprise hosting organizations are often performance and security related. While they rarely see people get hacked (thanks to Imunify360), many of the security breaches stem from site owners who do not keep their plugins, CMS, or PHP version at the latest version. It’s not standard to enforce people to use a specific version or to keep their plugins or CMS up to date, but it leaves these site owners vulnerable to compromise.

customer-service (1)

70% of all customer support tickets are resolved with a single reply

maintenance

MTTR (mean time to recovery or mean time to restore) within 30 minutes

Slow Plugins

Many sites today run WordPress, and many WordPress plugins or themes are not written in such a way that makes them optimal for speed. Combining that with an excessive amount of plugins per site, sites spend a lot more time in PHP than they ideally should.

slow plugins

The example of Software modules/plugins that slows down the website:

Software type – a name of the WordPress plugin

Software module – the number of identical SQL queries

Duration – plugin execution time

Duration (%) – plugin execution time as a percentage of the total duration of the request

Tracking plugins for WordPress, managing the Facebook Pixel, Google Analytics, Google Ads Remarketing, Pinterest Tag, Bing Tag, and virtually any other script always adds quite a bit of loading time.

Custom menu builder plugins can severely affect performance. Hosting4Real recently started hosting a site where plugins for menu customization is responsible for more than 55% of the load time for a WooCommerce shop (several seconds of load time).

Plugins for SSL redirection do output buffering to replace http with https. This generally isn’t a problem unless you have bigger WooCommerce sites. The more efficient way to perform a redirect to HTTPS is to do a search and replace in the database.

Search plugins often offer a “lightweight” way to search a site. Unfortunately, these plugins often search the entire database and destroy performance on larger sites.

Several official WooCommerce plugins that perform search filtering destroy performance, and they are often used in large ecommerce sites.

Long-processing SQL requests

slow database queries 1

The example of slow Database queries:

Query – the executed SQL-query

File – the file and the line of the executed query and backtrace

Calls – the number of identical SQL queries

Duration – execution time as a percentage of the total duration of a request and the function processing time (in brackets)

Software module – a WordPress plugin name from which the request was completed. If the request does not belong to any of the WordPress plugins, the name of the function that executed the given request is displayed

1

Queries such as full-text search in MySQL performed are generally inefficient

If people are implementing something like full-text search functionality, we often see people opt for WordPress plugins that allow searching in the database directly. Since full-text search (or rather the way plugins perform it) isn’t very optimal, we often see performance issues because MySQL simply isn’t able to properly use indexes to speed up the query. This will cause large amounts of table scans. For large sites (we host a website with more than 100,000 blog articles), these queries can end up taking multiple seconds (and in certain cases 10+ seconds).

For cases like this, where even trying to optimize the query seems impossible, we generally suggest people going for systems that are better suited for full-text search, such as ElasticSearch.

That’s also why we see Magento 2.4 dropped support for MySQL search and requires people to use ElasticSearch, since it greatly improves the performance as well as lowering the resource usage to provide the same (or even better) results to the customers.

Obviously, a lot of plugins both in WordPress but also other systems like Prestashop and Magento rely on performing queries in the database.

In some cases plugin/module or theme developers are very good at writing optimal queries, understands indexing and how MySQL actually handles data, so even at scale they’re able to execute queries efficiently without much overhead.

Group 1

Queries performed where there is a lack of proper indexing on tables (or the use of them)

left-quote

Sadly, I think in most cases, while plugins might work for smaller websites, they’re often not tested for scale, that being either high traffic, a large amount of pages/products in the database, or in worst case a combination of both.

Table scans or lack of proper use of indexes are generally bad, but for most smaller websites, this doesn’t generally matter, because queries are often fast enough for it to be a problem. But as things grow, these badly written queries will show how bad they’re actually performing.

If we identify slow queries when running PHP X-Ray, we’re often taking this query and replicate it using analysis to see what’s going on. We’re identifying what columns are used for the `WHERE` and `ORDER BY` conditions of the query, and it’s quite common we see that there could likely be added an index to a given table to simply allow MySQL to actually utilize an index when performing the slow query.

The last example we had was a Prestashop where the site performed a query on the table `ps_category_product`, where the way it performed the query, it would take about 1500 milliseconds per query to execute due to a full table scan being performed, this query would be performed 4 times for every pageview on the webshop.

After adding a simple index to the table, we saw the query times drop to 8 milliseconds. So a pageview went from spending 6 seconds in MySQL for those 4 queries to spending just 30-35 milliseconds. An improvement of 171x.

That’s a big win for seeing the query, identifying what the query did, to then adding an index and seeing the immediate effect.

Long-processing External requests

slow external request

The example of slow External requests:

URL – the URL of the executed request

File – the file and the line of the executed request and backtrace

Duration – execution time as a percentage of the total duration of a request and the function processing time (in brackets)

Usually when we see this it’s due to plugins finding it “normal” having to communicate with some external system for X actions. When the external system then faces downtime, it results in sites becoming super slow. There’s not much we can generally do about it, other than informing the user what’s going on, then the user can decide whether they’re gonna use a different plugin or wait until the service is back online again.

Rarely do we see problems where it’s something we can fix if it’s external systems. Luckily there’s not many plugins who communicate with external systems (except things like Facebook, payment gateways etc).

Long-processing System functions

slow system function 1

The example of slow System functions

File – the file and the line of the executed request

Duration – execution time as a percentage of the total duration of a request and the function processing time (in brackets)

The smarty cache cleanup process in Prestashop for sure comes to mind. The way Prestashop generates its smarty cache isn’t very optimal. If you have 30.000 products and 100 categories, you can be rather confident that there will be more than 400k+ smarty cache files stored on the disk if the whole page is relatively active. Prestashop doesn’t deduplicate cache files, so if the checksum of the file content is similar, then it would only store it once (It used to do this in Prestashop 1.5).

As a result you’re first of all ending up with a massive disk usage of cache data that’s mostly useless, but when Prestashop then has to clean up some of these files, it will start to crawl and delete files recursively in the cache directory. If you have 100k+ files, this will take plenty of time.

For cases like this, we generally suggest people to use Smarty Caching in MySQL, since in MySQL it will actually de-duplicate the data as it should, and only store the copy once – now, it’s done on a site per site basis, because some sites simply just become slower with using Smarty Cache in MySQL, while others become faster. I think for small sites, generally use the file system. For complex/large sites, storing it in MySQL often speeds things up.

Apache Connections Limit

One more common case of website destructive work is when the average load number shows acceptable value but the website doesn't load from time to time. In this case, there could be multiple reasons for that, but simply looking at the Centralized Monitoring dashboard you can notice when the Apache connections limit was reached for a particular website and doesn't increase anymore. This means that the number of slots should increase. Additionally, you don't need to deploy full monitoring for some specific important client. No need to set up SNMP or write custom scripts and monitor it all on a separate virtual machine. With CloudLinux OS Shared Pro everything is working out of the box.

It also depends on Admins' experience, but no one really wants to spend time playing guessing games no matter how long it would take. Centralized Monitoring simply allows you to focus on the business, and not wasting your time on problem investigation.

503 Server Error

A common PHP issue reported to support is a 503 server error when LiteSpeed is implemented. A 503 error indicates that the server cannot handle the request, which can be purposely returned when administrators take the server down for maintenance, or it could mean that the server is overloaded by requests. In this scenario, the error persists but users have not reached their LVE EP limits set by server administrators.

The cause of the issue may be due to CSF/LFD killing PHP processes.

To mitigate this case Administrators can check logs if it’s installed using the following command: grep -i kill /var/log/lfd.log

To resolve the issue permanently, administrators must modify the csf.pignore file to ignore specific processes by adding:

pexe:/opt/cpanel/ea-php.*/root/usr/bin/lsphp.* to /etc/csf/csf.pignoreand then restarting CSF using csf -ra

or in case the lshttpd binary is unknown to LFD, by adding: 
pexe:/usr/local/lsws/bin/lshttpd.* to /etc/csf/csf.pignoreand then restarting CSF using csf -ra

Mitigation

Slow plugins were always a pain point for Hosting4Real to figure out what exactly caused performance problems across a large amount of installed plugins. Once they found the offending plugins, Hosting4Real configures customer sites to natively perform redirects to https and help customers switch from using plugins to native redirects for better performance. For functions such as WP Search, Hosting4Real offers customers the option to purchase access to a managed ElasticSearch cluster, which provides better and faster search capabilities.

But now, with the PHP X-Ray tool for End-Users, people can trace their website performance, identify what caused the bottleneck and proceed to mitigation with plugin authors or simply switch it off.

Here is how it works

correction
Create a tracing task in PHP X-Ray.
correction
Specify the site URLs or domains that have performance issues.
correction
Visit the site and perform an action. For instance, submit a form on the site to perform a POST request, which will trigger PHP X-Ray data collection.
correction
Return to tracing dashboard to review feedback. PHP X-Ray sorts requests by order of the slowest requests at the top so that you can prioritize issues.
correction
View the Details page to get additional information about the performance issue and feedback on the root cause. For instance, if a WordPress plugin uses extensive resources for the request, you will find the details on this page.
correction
Disable the plugin in the CMS administrative dashboard.
correction
Revisit the site, and performance should improve. The Details page in the trace dashboard should also show no performance issue.
correction
Done!

Conclusion

Hosting providers measure success with two parameters: MTTR (mean time to recovery or mean time to restore) and MTBF (Mean time between failures).

CloudLinux OS Shared Pro considerably reduces this time by allowing server administrators to deploy tracing tools to find the offending component responsible for performance issues and enables sysadmins to monitor all their servers, determine the load on each one, and identify the users creating the most load. If a domain is using an inordinate amount of CPU, memory, or disk resources, this tool helps bring it under control.

Performance issues no longer need hours of manhours to determine the offending resource. For Hosting4Real, things affecting the whole server’s availability trigger alerts from their own monitoring and send the notification directly to an engineer - so they're aware of issues within 1 minute of something being affected. With that said, Hosting4Real resolves more than 70% of all customer support tickets with a single reply and within 30 minutes.

We have out-of-the-box, priority support, problem-focused monitoring that does not require implementation and continuous support by engineering teams in the future. Instead of building a full solution in-house,CloudLinux OS Shared Pro gives administrators requiring little configuration -- just click and deploy.

right-arrow
Check how CloudLinux OS Shared Pro Can Reduce Your Time and Effort Required to Administer Web Servers

Related Materials

AdobeStock_188695030
down-arrow-1

How to find performance bottleneck with Centralised Monitoring
AdobeStock_271134500
down-arrow-1

PHP X-Ray for End-User
AdobeStock_183268427
down-arrow-1

Troubleshoot and fix a WordPress performance problem

Frequently Asked Questions

What is CloudLinux OS Shared Pro? Is it an entirely different OS?

CloudLinux OS Shared Pro is the same operating system, yet with some extra features added on top. If you are an existing CloudLinux OS user, nothing changes for you! However, there is always an option to try some extra features thatCloudLinux OS Shared Pro brings to the table.

What CloudLinux OS kernel versions are available for conversion to CloudLinux OS Shared Pro?

Any CloudLinux OS version can be upgraded to CloudLinux OS Shared Pro.CloudLinux OS Shared Pro also will include extended lifecycle support for CloudLinux OS 6 for free to our OS Shared Pro customers.

I've upgraded CloudLinux OS to CloudLinux OS Shared Pro. What happens with my existing servers? Do I have to do any extra steps on a server-side?

As long as your system receives fresh updates, you're good to go! If you haven't updated the system recently, make sure that you have updates compatible withCloudLinux OS Shared Pro installed on the server. Here are the requirements for the PHP X-Ray and Centralized Monitoring components.

I've purchased my CloudLinux OS license somewhere else (not directly with CloudLinux). Can I still upgrade it to CloudLinux OS Shared Pro?

Yes, you can.CloudLinux OS Shared Pro is only available direct from us, so you will only need to create a CLN account with us, purchase yourCloudLinux OS Shared Pro licenses there, and deactivate your old OS licenses with your reseller.

I have a CloudLinux Reseller account; I do not resell licenses and still wish to subscribe to CloudLinux OS Shared Pro. Can I?

Yes you can. You can purchaseCloudLinux OS Shared Pro licenses for your own servers via CLN as all other our products.

What if I want to useCloudLinux OS Shared Pro while my licenses were purchased somewhere else?

In that case, you can cancel CloudLinux OS reseller licenses & purchase them with us directly. If you have any doubts along the process, don't hesitate to contact our team for assistance.

Does Centralized Monitoring provide notifications of specific usage?

Yes, you can set up the custom notifications and alerts most suitable for your infrastructure.

Does Centralized Monitoring require an installation of a specific agent or it’s integrated onCloudLinux OS Shared Pro packages?

Centralized Monitoring special package will be automatically installed on all yourCloudLinux OS Shared Pro servers after the license activation.

Does Centralized Monitoring give the ability to configure custom dashboards showing custom groups of servers?

No. But this functionality can be added later if we’ll receive enough requests. Please contact us at marketing@cloudlinux.com if you are interested.

Do you need to install extra WordPress modules for PHP X-Ray?

No, you don’t need to install any additional software, PHP X-Ray works right out-of-the-box.

Documentation

PHP X-Ray for Admin
documentation

document

PHP X-Ray for End-Users
documentation

paper

Centralized Monitoring
documentation

seo-report

Back on top

privacy shield certified
aicpa soc
pci-dss
eu gdpr compliant
© 2024 All rights reserved. CloudLinux Inc.
Terms of Use | Privacy Policy | Vulnerability Reporting | Legal

Call Sales at +1 (800) 231-7307
Email sales@cloudlinux.com