Rectifying Instability

UnixGuru prides itself on providing reliable stable hosting, but in order to understand what makes hosting unstable lets look at what problems shared hosting has.

 

What makes hosting unstable

  • *Unpredictable loads due to many different types of sites
    • -Unoptimised PHP Code
    • -Memory Issues
    • -Unoptimised MySQL queries
    • -Insecure code, leading to system compromises
  • *Sites running on shared hosting, thataretoo resource intensive due to high visitor numbers
    • -Too much CPU is allocates to a single site or user
    • -Too much I/O is allocated to a single site or user
    • -Too much memory is allocated to a single site or user.
  • *Hackers attempting to gain access, using resources
    • -Attempting to send spam through the server
    • -Attempting to login to
      • -SMTP Mail brute forcing
      • -IMAP Mail brute forcing
      • -POP Mail brute forcing
      • -CMSloginbruteforcing
        • -Wordpress
        • -Joomla
        • -Drupal
  • *DDoS of a website bringing down whole server

Unoptimised PHP Code

Usually a piece if sub-optimally optimised code, like a badly written plugin or subroutine, can use alot of CPU, Memory. This might not be a problem until your site becomes popular. We have tried to solve this issue with Varnish Cache, which sits infront of your site and if asked the same question (the same page is visited, and you are not logged in) the same answer is returned directly from memory. This helps stop the sub-optimum code from having to run over and over, and basically only requests a re-run every 120 seconds. (If your site is getting that many hits).

A single user account is only allowed to use a Maximum of 200% CPU (2 Cores). So if you have more visitors each visitor will be a little slower.

i.e. 2 visitors get 100% each, 3 visitors 66% each, 4 visitors 50%, 5 visits 40% … 20 visitors 10% each and so on.

If a site needs more than 2 CPU cores, then it’s time to move off shared hosting to something more substantial. Varnish cached pages do not count towards your CPU Time.

Memory and Apache entry points are capped at 2GB of Physical PHP Memory and 25 Apache Entry points. (E-commerce packages have significantly more memory allocation).

25 Apache entry points does not sound alot, but if you are serving 25 customers at once, and a page takes 5 seconds to generate thats ((25EPs * 3600 Secs * 24Hours) / 5 sec/page) = 449280 page views.

If you getting this many page views, you will probably need to upgrade your hosting from shared hosting.

Memory Issues

Each user runs in their own LVE (Lightweight Virtual Environment) and is allocated a specific amount of memory.

If the user exceeds the amount of memory that they are permitted to use, no further EPs (apache Entry Points) can be created, stopping a single website from using all of the memory on the box.

(On UnixGuru hosting, only .php pages use Apache, static objects are served by nginx and are not subject to these limits).

Resource Intensive Websites

Most of the time when we find a site has become resource intensive it’s under some kind of attack.

i.e. WordPress having a bruteforce attack etc. (Login mechanisms cannot be cached so this re-introduces a problem)

We have two robots which are looking at these attacks.

1) The first parses the logs and looks for “Slow Hackers”, and we can spot IPs of hackers who are trying to log into CMS systems which are owned by UG Customers or differing resellers.

The IPs of these attacks get temporarily blocked in the firewall, which significantly slows down any attack.

2) The second robot looks at the Status Output from the web-server. If an IP is actually trying to log in with parallel login attempts, that’s not a human and the IP can be blocked, locking out the hacker/robot.

 

Superior Hosting Stack reduces necessary resources

Varnish greatly reduces the resources needed to keep serving pages.

NGINX serves all the static data, significantly reducing the load on Apache and stopping Varnish getting bogged down with caching images already cached by the operating system.

Optimum-Cache sits between processes and the operating system filesystem cache, and de-duplicates the cache, so we don’t have to cache WordPress Core, Joomla Core, Drupal Core, Magento Core etc, over and over again.

(It will keep 1 version of the same file in memory, obviously if you customise a file, it becomes a separate object in cache.)

Sites cannot use more than their specified CPU allocation, so other tenants site continue responding as usual.

UnOptimised MySQL Code

The CPU of a user’s apache/PHP processes is added to the CPU used by MySQL, and compared against the limit allocated to a user, and the user is slowed down so that it never exceeds the allocated CPU allowance.

Again this stops a single user taking up all of the servers CPU and bringing the server down.

Again, varnish caches the output of PHP scripts relieving the database from having to perform the same queries over and over.

Insecure Code

CageFS provides each user account with their own virtualised filesystem and each user is separated from every other user on the system.

So if a users site is compromised by a hacker, the hacker is unable to get to anyone else’s files for the servers “real files”.