Archive for the ‘discussion’ Category

Social This*

Posted by David on March 5th, 2010 - discussion | No Comments »

Lately we’ve been trying to boost our social presence around the web so we can connect with all of you, so we thought we’d share where we’re currently at. We always enjoy chatting with you, and hearing what everyone is up to.

  • Facebook – Become our Facebook fan! Feel free to chat with us, ask questions, or share your website!
  • LinkedIn – If you’d like a more professional environment and would like to connect with us, we have a company page over at LinkedIn.
  • Twitter – This is where we’re most active, and most of you are probably already our friend, but for anyone who’s not, we’d love to be!

Let us know if you’re current anywhere else, so we can sign up and chat with you there!

Post to Twitter Tweet This Post

Feedback: CPU Usage

Posted by Jules on February 9th, 2010 - discussion, feedback | 9 Comments »

Much in line with our previous post on upcoming MySQL quotas, we’re always looking for ways to try and improve the quality of our hosting for everyone. One of the things we’re currently looking at is the CPU usage of accounts that we host. Currently, you should be aware that within our AUP we have a limit on the running time of processes. If they exceed 60 seconds (such as a badly coded script that may generate an infite loop) it will be terminated. We realise that there are many instances where a user may wish to run extended tasks that may take longer than 60 seconds to run, such as updating a shopping cart with inventory, or for uploading reasonably sized files. Under the current system these processes will likely be killed. Usually when this happens, some of you have noticed anomalies and have opened a ticket. Usually we’re very flexible with this and have added exceptions accordingly to ensure that your scripts work, but we’re looking at better solutions.

The key area we’re now looking at is daily CPU usage per account. This gives us a far more accurate representation of single site resource usage consumption, than on a per-process basis where you may have a very high period of activity, but not much happening for the rest of the day.

This is a very difficult topic to write about and discuss, since it effectively hits at the very heart of a topic which is essentially “Is my site fit for shared hosting?” Many hosting providers in the past have put limits in place on resource consumption, and whilst we don’t want to do that, we do need to have limits in place which provide a guideline we can use to determine when a site has exceeded shared hosting placement and needs its own dedicated set of resources.

At this*, as you should know, we don’t oversell our servers. This lets your sites run very well in all but the most extreme of conditions. Whilst we don’t oversell, given the nature of shared hosting, it’s simply not feasible for us to host websites which by their nature or by the mere traffic they receive, out-consume others by many many times. Out anti-overselling policies simply aren’t in place to allow very popular and active websites to “get by” on a shared hosting account without needing to upgrade to something that better suits them.

Many people may instantly jump to the conclusion that “If you need to take action, you must be overselling!”. That’s simply not the case at all. To throw an (extreme) analogy your way; if we deploy a brand new server and had a single account running on it that consumed approximately 60% of the load (permanently) – that’s most certainly a site that needs its own server. It’s not financially viable for us, or any other hosting provider out there, to maintain a website that large at the cost of shared hosting.

We’ve been monitoring accounts for the past few weeks, and we think we have a good idea of a guideline on CPU resource consumption in a “minutes per day” measurement. The sites that have currently exceeded our approximate guideline generate (on average) at least 750,000 hits (and in some cases much more) every day. We feel that’s certainly beyond what you would expect from a shared hosting account, and we’re happy that the guideline is “fair”. If we were to implement a guideline or “limit” on CPU minutes, we would not take immediate action on websites – such as a suspension or termination. Instead, we would notify the user and offer them an alternative solution, or at least make it clear that action needs to be taken, whether that’s a VPS or Dedicated solution with us (coming soon) or another provider. Our intention isn’t to disconnect anyone and leave them without their website. Your websites are important to us, and ultimately we want you to be in the best possible position.

To be clear, this isn’t a package issue. We’re more than happy for our lowest package users to use exactly the same amount of server resources (CPU and RAM) as our highest package users. This is fundamentally a Shared vs VPS/Dedicated issue.

We’re looking for your feedback on this subject. Do you believe what we’ve outlined is fair? Do you have any questions or suggestions on this topic?

Post to Twitter Tweet This Post

MySQL Database Sizes

Posted by Jules on August 20th, 2009 - discussion, feedback | 2 Comments »

One of the things not very many people consider when using shared hosting is the size of their MySQL databases. Very few hosts that I’m aware of routinely monitor and tweak their MySQL configurations in order to provide the best possible performance, and resultingly MySQL performance can often be quite slow. At this*, we monitor many things that typical hosts don’t, and one of these things is our MySQL configurations – along with the sizes of users databases and the number of tables within. This process is always ongoing, and as user data changes within the database, so do the settings and modifications we make to compensate. And it works. We’ve had some positive feedback from people who have moved from other hosting providers and have noticed that our MySQL performance is significantly better. But, it only works if we keep things under control….

Read the rest of this entry »

Post to Twitter Tweet This Post