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

This* cPanel theme is back!

Posted by David on March 4th, 2010 - announcements | 6 Comments »

Hoorah, our snazzy cPanel theme is back! It took some time ironing out the bugs due to cPanel’s recent upgrade, but its all finished and back up for all of you to use!

On another quick note, we’re making huge leaps with the new website, and it should be up and running before you know it, so look out.

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

This* Redesign

Posted by David on February 5th, 2010 - feedback | 12 Comments »

Over at the This* offices we’ve been hard at work on changes to both our website and our hosting packages. Since all of you will be the ones visiting our site, we thought we’d give you a taste of the redesign to see if its too your liking! Click on the images below to enlarge!


Enjoy! :)

Post to Twitter Tweet This Post

Implemented: MySQL Quotas

Posted by Jules on January 31st, 2010 - announcements | No Comments »

As per our previous post on the MySQL Quota changes, we have now implemented MySQL quotas across the board. This post will try and cover all the details you may need regarding the new quota system.

What is the quota size for databases now?
The quota is currently hard-coded to 256MB. There are no plans to increase this in the future.

What will happen if my database is over quota?
Your database will have the UPDATE, INSERT and CREATE permissions revoked. This will mean that no new data can be added to the database until you reduce the size to less than 256MB.

Will this cause an error on my site?
Unfortunately this is impossible to determine, and fundamentally depends on how your site is developed. Some sites will generate a MySQL error, perhaps related to invalid permissions. Some sites may be less friendly and show nothing at all. If you’re experiencing odd problems, you should first check the size of your MySQL database(s) within cPanel.

I’ve reduced my database size, when will my site/database be working again?
The quota system is scheduled to execute every 5 minutes, so your site/database will be working within 5 minutes of reducing the size.

Will you notify me if my database is over size?
Unfortunately, due to the very dynamic nature of databases, and various limitations within our billing system (currently), we are unable to notify you if your database has had the permissions revoked. We are working to include this, and other account notifications in a future client area, but presently this is something you will need to monitor manually.

We apologise for any inconvenience that this change may cause, and we hope you understand our reasons for implementing this. As always, if you have any questions, comments or concerns, please let us know.

Post to Twitter Tweet This Post