Prior to the move to the new systems, resource usage visibility was something that only our Monitoring Team has access to.
However, a decision was taken to broaden this.
This was done so that customers like you can have daily updates on what their account is doing.
It is an attempt to show you what might be needed to optimize a website's performance.
We did this by sending a notification every 24 hrs to you.
This could include CPU usage, RAM usage, and/or concurrent processes for that account.
The goal is to help a customer identify where he/she, or they could optimize things on the website to reduce such notification.
You will receive this:
- if your site experiences high peaks in inbound or outbound traffic it can exceed allocated resources.
- if there are pages on your site that have speed issues, (an increase in inbound traffic or concurrent page requests can push the site over its resource limits).
- if backend operations such as imports and exports create a significant load, which in addition to normal traffic can cause resource limits to be exceeded.
- if web-crawlers make a high number of requests per second.
The notification you are receiving is not to be seen as an error.
Rather, it is for informational purposes.
See it as your own President's Daily Brief (PDB) containing information/analysis on your resources over the past 24 hours.
On our platform, customers pay for what they need and get exactly that resource.
For each account, we try to be as fair as possible so that the system delivers optimal performance.
But we want customers to always have clear & transparent visibility of the resources their account is using.
It is the best way to understand a website's true capacity while helping with capacity planning.
Having said that, our team also has access to the same information.
Often than not, you may not even notice the difference on your website.
Should this become a real issue, we often do preliminary investigations to understand the cause.
Then update the customer on what we believe is the best course of action.
IO:
When a user clicks or accesses any information on your website, a request is sent to the host machine.
Disk I/O includes read or write or input/output operations (defined in KB/s) involving a disk.
It is simply the speed with which the data transfer takes place between the disk drive and RAM.
Or the percentage of time such processes are waiting on the disk.
On our systems, the processes are throttled (put to sleep; not stopped or killed) when the set limit is reached.
Why limit IO?
For every web server in existence, disk IO is probably one of the scarcest resources.
This is especially true in shared hosting where each account/application consumes resources differently.
So capping the upper limit for each customer is very important.
EP (concurrent connections):
This represents the max number of concurrent connections that can run simultaneously on your account.
Its purpose is to define the maximum amount of active connections to the webserver.
Please note that external processes (like cron, Sendmail, Exim, MySQL, etc.) are not counted as they are considered as a single connection.
One of the reasons this limit exists is to prevent DoS attacks against your web server.
Typing up all the Apache connections available by hitting slow pages on a server is one popular attacks methods often used.
When all the Apache slots are used up, nothing else will be able to get through to the webserver.
Responding slowly to requests even cause more connections to be tied up.
RAM:
This is the amount of physical memory used by your processes.
When physical memory crosses over the limit, the system will first free up the memory used for the disk cache.
If that is not enough, it will kill some of the processes which may cause your webserver to serve 500 and 503 errors.
The rule of the thumb is that:
- once a website reaches the limit of resources that have been set, the site will begin to slow down.
- once the number of entry processes (Apache/HTTP requests is reached), the website will get a 508 "Resource Limit Reached" error message.
- if the site is limited by CPU or IO, then the site will start responding slower.
- if the site is limited by memory or number of processes limits, then the website will receive 500 or 503 errors. This means that server was unable to execute the script.
You can also check this via Metrics >>> Resource Usage >>> Snapshot.
Clicking on Snapshot and selecting a date will give you an overview of the previous usage which could be used to model future usage and impact.
You can also use Metrics >>> Awstats (Webalizer) to see usage statistics and what bots and human visitors are accessing.
Customers also have access to PHP X-Ray (included free to all accounts) which can help you isolate an issue that the website may be having.
PHP X-Ray provides detailed information on performance bottlenecks that involve the CMS such as WordPress, Joomla, Drupal, etc.
If a site has sluggish plugins, database queries, functions, or external calls, this tool will help you pinpoint the underlying problem.
