My Overloaded Server Story

From time to time I face problematic accounts that overload our servers. Usually these accounts are hosted on shared (note: cheapest) packages. I would like to highlight the issues and sort things out.

There are lots of reasons for a simple account starting to overload a server, one of the most common reasons being that the number of visitors to a website soars (traffic), or, the code powering the web site is not optimized, is out of date, has known security holes, or any combination of the above.

From a traffic standpoint, a site that was used to having only 100 daily visitors could skyrocket to tens of thousands overnight because of some specific unpredictable event that came out of nowhere. This is generally a good problem to have, as most web site owners would like to have websites which have become extremely popular.

One of the biggest misconceptions is that bandwidth usage and load are somehow related. High bandwidth usage doesn’t mean that a website starts overloading the whole server. I’ve dealt with  accounts that have used hundreds of gigabytes of bandwidth over the course of a couple days and at the same time, didn’t create any noticeable load. That is in part because our shared servers are extremely powerful and have super-fast uplinks, but also because the site was properly coded…

Now back to the increased number of visitors situation. When can this be a problem? When poorly coded and unoptimized scripts try to process this traffic on a web site. Some sites connect to the database server, get the information from the database, and close the connection.  This is how things are supposed to work. Other sites leave connections opened indefinitely. This is bad! A well coded script will always close the connection when it is no longer needed. There are always exceptions to the rule, but for the purposes of this article, closing database connections in a shared environment is the expected behavior. Without trying to get too technical, every server has a finite number of connections that it can support. Too many connections which are left opened to the database server eventually uses up all the available connections, which in some cases can contribute to overload.

Another common form of overload in the database is when a script tries to run a poorly planned and poorly constructed database query. In other words, there is a right way, and a wrong way to pull data from a database. Unfortunately, there are many many more “wrong ways” than “the right way” and users often run into this problem. Imagine a pile of 10,000 of marbles (the data in the database). You know that you want to pick out a 14 blue marbles and present them to somebody. Would you pick up all 10,000 marbles (overload!), move it across the room, (more overload!) then set them down and blindly reach into the pile, grab a random marble, and then look at it to see if it was a blue one, then if not, keep reaching into the bag until you had the desired result (inefficient!)? Most people wouldn’t do that. They’d look in the bag and reach for the exact one they wanted. Database queries work in the same way.

Other “bad” scripts can end up becoming zombie processes on the server. I can’t say that our fantastic (yep, it is) technical team can’t cope with tasks like killing zombie processes, or getting the load down to acceptable levels, but sometimes the load can raise to 10x or 100x the capacity for which the server’s processor was designed for, in only a matter of seconds.

When this happens, it can take an admin a very long time to get the server back to normal load levels, because the server responds slowly. I am sure you have seen your own PC lock up for a short time, or even permanently, well, servers have the same issues when something bad happens…Enter a command…sit and wait…then it finally executes (hopefully), or in some cases, a reboot is required.

To sum up, we have two cases. In the first one, a web site has a huge amount of visitors, but it doesn’t cause load problems. The site simply consumes it’s available bandwidth allocation, and our customer contacts us with an upgrade request to add more bandwidth to their account.

The second case is when a site goes crazy and uses up all the available connections, or overloads the server in some other way. This can lead to a server that does not respond, or a server which may even require a reboot in the worst case. Rebooting a server can launch a file system check, over which an admin has no control over, and everyone has to wait until it completes before the server comes back online.

When a server has to be rebooted, it usually is caused because the software running on a user’s web site has not been optimized. What I mean by that is, a novice has a self-written script or WordPress instance with 10 million plugins installed on it. The plugins themselves being written by 10 million different developers, many if not all of them being novice programmers themselves. OK 10 million is a bit of an exaggeration, but I’ve seen blogs with upwards of a hundred plugins and that means hundreds of different and very likely, novice programmers, and that is kind of scary! Did anyone see a zombie around here? Braaaaains….BRAAAAAINS!

In my position with the company, the second case is more challenging to deal with. Sometimes I have to contact a customer and say, “Hello Mr. Smith, I am sorry to say that your site has overloaded our server, and to protect the other customer web sites which share this server, we had to disable your site.” And the typical response? It is usually something along the lines of: “Why me? I don’t have billion of visitors, just 10000 a day! Why should I upgrade? You just want more money! I won’t go for it! I didn’t change anything on the web site, why is it different now? I have not updated my software in 15 years how could it just break?” Then I try to answer each question as reasonably as possible, but I rarely win the case. And when I lose the case, our otherwise faithful customer  will start looking for another host, taking his problematic scripts with him, and later he will switch to yet another host…and on to the next. Eventually he may lose interest in the site because it is so problematic and just scrap the project never to return to the web again.

At the end of this long and painful journey, these types of site owners face several transfers of their web site, and finally they agree, “Yep, GlowHost Support was probably right, I need to optimize my scripts or move to a dedicated server.” Man! Wouldn’t it have been easier to just do this from the beginning? Not that I blame this type of person, because I too like to learn by trial and error, but as I grow wiser, I am getting better at knowing when to take the advice of a professional, especially when it comes to making my life easier, calming my nerves, and freeing up my personal time.

So why am I writing this? Because my boss said I better come up with some fresh content for the blog of course! Just a joke, I actually wrote this on my own. I wrote this because it is something I experience on an almost daily basis and certainly no less than once per week and I truly want to help people navigate through the crazy world of online business. I wanted to share some advice in more detail here than I could ever hope to accomplish at our help desk, and I sincerely hope that it will help someone to avoid months of bouncing around from host to host. I may be biased, but I am pretty sure that 9 out of 10 times, they are not going to find a host better than GlowHost, and with those odds, I can feel their pain. I’ve worked at those other hosts, and I can tell you, the difference between GlowHost and “those other guys” is night and day.

Which reminds me of something else I’ve found which makes GlowHost different. The thing is, that when you go to another hosting company and tell them “My soon-to-be, ex-host, suspended my site and I hate them and they are terrible.” The other hosting company will usually, and gladly accept that person as a new customer.  There is a different attitude at GlowHost which surely costs us a lot of lost revenue on the short-term, but we feel pays off in the end with long-term, and happy customers who can rely on some the most reliable shared servers around. What I mean is, that very few companies have a philosophy like we do. If we receive a call from a potential customer where the caller states something like, “Hey, my ex-host suspended me…” we will ask for the reasons of the suspension and try to explain that if a script is written badly, switching hosts is probably not going to help, especially on the $5.00 shared hosting hosting plan they are calling about.

As you can probably imagine, it’s very difficult to convince someone to buy your services when you tell them that. Especially someone whose site was just disabled, who is already angry at the world, and is shopping for a host that will tell them exactly what they want to hear, which is something like this: “Sure we can make it magically work. Just give me your $5.00 and life’s problems will be solved.” The first hosting company that tells them exactly what they want to hear, is the hosting company wins their business. We don’t do that.

That’s not fair to the new customer, and it’s not good for our existing, long-term customers to put known overloaders in a shared environment which is only going to slow down their sites. Not to mention it makes everyone’s blood pressure rise, from the customer to the superhero technicians trying to save the day who are fixing servers at the same time they are dealing with grumpy customers. The frustrations involved with slow sites, customer complaints, and extra workload that it creates for everyone involved is something we are not interested in. Why do it? We love what we do which is trying to provide a reliable and affordable hosting environment, and to not make ourselves or our customers crazy, and it’s definitely not all about milking every last penny we can possibly scrape together.

If you are creating a new website or have an existing web site and your web host contacted you for overloading a server, here are some simple guidelines you should follow:

1. Ensure to use an engine that won’t cause high load. When I say “engine” I simply mean a script or app like WordPress or any other software which runs on your web site. Try to use as few plugins as possible, and use ones that have been updated recently, which have good ratings and responsive support when support is offered. Remove any plugins which are not in use, and keep your scripts and plugins updated to the latest versions at ALL times.

2. If you are going to hire a web-developer, check his work, his references, and make sure that he is a professional. There are many freelancers out there who can put some simple code together to make your web site do what you want it to do. But this does not mean the code is optimized, or that it is secure. A good developer is hard to find, and it is worth waiting until you find the right one. Ask the developer what software platform he usually develops for. Check if your host meets requirements of the web-developer preferred platform, and make sure the platform that you agree on is portable. Portable would be a software which is supported by many web hosting companies. Portability is important should you need to switch to a different web host some time in the future. Portability also has one hidden advantage, it means that there are lots more developers out there who can help you to code your software. The more specialized your software’s required operating environment becomes, the harder and more expensive it is to find developers. You do not want to be married to one host forever…unless it is GlowHost of course.

3. If you have noticed that the number of visits is rocketing, you can start making some money, quite easily in fact. One thing I always wonder about is, when a customer has a website with tens of thousands of visits per day says “We don’t have money, and make no profit at all.” And I’m not talking about some educational portal without ads, these are usually commercial sites with this complaint!  The thought that often comes to my mind is “Why would they pay for and put their time into maintaining an unprofitable website with this number of visitors?” There is always the possibility to place some Google or other PPC ads, sell some banner spots, sell text links, or any number of things to help cover the costs of  a hosting package that will actually work for them, not against them. I also can’t remember many customers who had overload problems on our semi-dedicated packages. These types of customers generally know that they need more resources and don’t search for freebies. There is a Hard Limit of an absolute maximum 30 domains on these type of shared servers, not hundreds or thousands, and really, from looking at them behind the scenes, there are usually only about 20 at any given time.

4. If your website is successful, but you have a note from your host that it is causing load – don’t just sit and wait until they shut it down or suspend it. Try to optimize your scripts and databases or move to a package with more resources allocated if you don’t have the immediate funds or time to search for a qualified developer. And don’t just hire the first “developer” you find on the Internet! One case I can remember recently is one of our customers started out on a simple shared package and once he realized that he had outgrown his shared hosting package (started causing load), he asked us for an upgrade and we helped him to move to a dedicated server within several days. As a result, he got even more visits, because his site was online at faster speeds, more consistently, and he made more money since his server was able to cope with the number of visitors that his site demanded. If he did what the great majority of site owners in his position did, he would have wasted several months switching hosts, dealing with slowdowns, being offline, and loosing visitors forever. Who wants to attend a website that rarely works? Nobody!

If you are reading all the way down here, congratulations! I hope I was able to help some people out, and look for future articles from me in upcoming posts on the GlowHost blog.

I love to hear feedback and comments. Please post below to tell me what you think!