What we Need

We’re looking for someone to help design and develop the new client area with us. The key goal of the new client area is dramatically improved user interface and accessibility. The client area currently runs off WHMCS using the Smarty templating engine, but familiarity with this isn’t required – just the ability to code valid xHTML and CSS. The current client area feels very confusing and doesn’t ‘flow’ very well at all. We’d like to change that and redesign it completely from the ground up, so we can present the correct information where it’s needed and in a manner that’s easy to understand. Essentially we want a clean and accessible user interface.

Ideally we’d prefer someone who isn’t in school or college, to prevent the distraction from important curriculum work. Experience with jQuery or general Javascript would be hugely advantageous, as is PHP/MySQL. These extras are very helpful, but not required – so if you’re a competent designer who can also output their work into xHTML and CSS for the web, we’d still like to hear from you!

So, to recap; are you familiar with designing user interfaces? Can you design clean, easily accessible control panels/backends? Can you also code valid xHTML/CSS?

If you’re interested in applying, or have any questions, please e-mail jules@thiswebhost.com. Please be sure to include examples of your work.

UPDATE: This is not a request for a full or part time position, merely a request for work. You will be required to work remotely, so you are not needed in-house.

Tweet This Post

• 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!

Tweet This Post

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?

Tweet This Post

Within our AUP (Acceptable Usage Policy) we make a point of mentioning that whilst there’s no hard limit in place for MySQL database sizes, we would consider the 256MB-512MB range as “excessive” for shared hosting. 256MB may not seem like a lot to you, but for a database that’s often a heck of a lot of data and records.  To give you some idea for comparison, the average size of a database on our servers is currently at around 20-35MB, so our AUP is aimed at just over 10 times the average size. To give you further insight on the scope or severity of this issue, of the many hundreds of databases on our systems, currently only approximately 6 appear to be over this recommended AUP limit.

Why is database size a problem?

This is an issue that really needs to be looked at from several angles.

Memory

From a technical perspective and explained simply, the bigger the database – the more memory that MySQL consumes in order to read and store the contents. When there’s no more available memory, MySQL will read from the hard drive instead – much like the “Swap” or “Page” file within Windows. This is obviously much slower than reading from the memory and results in some performance degradation. Now, obviously on a shared hosting platform, unless you have very strict policies in place, it’s going to be almost inevitable that customer databases will (combined) weigh in at perhaps several gigabytes. This is certainly not uncommon and is to be expected. Left unmonitored, though, databases could grow to degrade performance is a very noticeable way.

Performance

One of the most common issues with MySQL performance is the often lack of good indexing and optimisation. I won’t go into the deep technical details here, but essentially the larger the database, the more records you can expect there to be inside. The more records there are, the longer it takes to search through these records to find the one you’re looking for. Indexing allows you to search through these records faster, but again this consumes memory and can only do so much for performance.

Backing up large databases from within MySQL, especially on a shared hosting platform, can also increase load due to locking tables and other issues.

Evaluation

As a shared hosting provider we need to evaluate and often be strict within our policies as to what is deemed acceptable or not on shared hosting. In my many years experience of server management, it seems quite evident that users simply do not look after their own MySQL databases to the point where they will let them grow and grow and grow until their hosting provider steps in and informs them that there’s an issue. Unfortunately, at the point where it begins to become an issue, it’s often a little too late and is more than likely affecting performance in a way where the database needs to be disabled or otherwise heavily pruned. Some users aren’t even aware their databases are growing. Installing plugins that log user activity is one of the common causes of huge database growth.

To try and prevent issues like this from happening, we’ve decided to potentially implement a solution that will limit the size of MySQL databases. The way this would work, effectively, is that if your database exceeds a certain threshold size outlined within our AUP (we were thinking 512MB), your “INSERT”,”CREATE” and “UPDATE” permissions would be revoked for that database. Your database would be left active, and will function to some degree, but no new data could be added until it is brought down to below this threshold. The obvious drawback to this solution would be that if you are using scripts to update tables that contain, for example, statistics – then this would perhaps display errors on your website.

So why the change?

Overall it’s to really maintain the performance of our shared hosting servers and to further draw the line between what should be considered a suitable site for shared hosting, and one that is not. For the legitimate databases that are genuinely this large, it allows us to confirm that indeed this site requires a different solution to the ones that we can offer.

Unfortunately it’s not a case of just including the MySQL database usage into your disk quota. There’s a world of difference between storing 512MB of static files and having a 512MB database, and this is fundamentally the issue.

Don’t Panic

At this point we’re really trying to gauge your feedback on this idea before implementation. As I stated before, currently as it stands only 6 or so databases would even be affected by such a change, so this is certainly not an implementation that is going to have any noticeable impact on the service of almost all of our customers. For those who are curious, your database sizes can be viewed directly from within cPanel, so you can see just how likely this is to be a problem for you.

We welcome your feedback on this issue, so please let us know what you think!

Tweet This Post