Occam's Razor

About two years ago, I went through a rather arduous adventure in rehosting. I regret to report that after about two years of hosting with site5.com, I have to rehost again.

The rehosting game goes something like this. Things always start out very promising. Your web pages scream back at you. Then, slowly, response time degrades. It is the usual problem: companies try to squeeze a bit more profit by shoving more and more customers on the same server. After all, that is the advantage of virtual hosting. Most of us cannot afford to rent our own dedicated server nor have the traffic to justify it. We want a web presence but do not want to pay for one that guarantees speedy response. In short, we emulate Jack Benny and are proud of it. Nevertheless, we sell ourselves on web host marketing material. I have yet to find a web host that does not claim to offer both fanatical support and low numbers of users on each server. This, of course, is just marketing hype. If some of them are actually honest, they are either charging a lot more or losing money.

Some months back things got to the point where my users were regularly impacted by slow server response times. I complained and things mysteriously got better. I think some other customer using the server was consuming most of the CPU, leaving customers like me high and dry. I assume to make things better they moved that customer to another server. However, over the subsequent months, I got more slowness. “White screens of death” were its principal manifestation. This is what you get from the web server (Apache, in my case) when the script takes too long to execute.

Sniffing around, I read the Apache configuration file on the server. Apache was configured to timeout after 15 seconds. I politely asked site5.com if they could up the limit so my users would not see white screens of death. They politely said no. The problem continued. I politely asked again. Again, they very politely said no. See, everyone on the server would be affected, because the web server’s behavior is shared among all customers. To make the change, the machine would have to be rebooted. Moreover, other customers might not like the longer timeout interval.

Particularly since my hosting contract was coming up for renewal, it sounded like it was time for an amicable divorce. The root problem in this case was that I could not change the Apache web server configuration settings to my liking. I doubt my scripts ran inordinately long. My most CPU intensive applications are on a phpBB forum I run, yet many sites run very busy phpBB boards without a problem. Therefore, most likely the root problem with my performance issues was that my server simply had too many customers using it. The white screens of death suggested this server was just above the waterline, and smart (or better moneyed) customers might want to abandon ship.

The question for me became where to go from here. I could find yet another company offering virtual hosting, sign up with them, and the problem would likely recur. I could contract for a dedicated server, but I simply cannot afford that luxury. The alternative was to use a virtual private server instead.

As a techie, I have been reading about virtual private servers for a few years. Using technology that to me is indistinguishable from magic, it allows one physical server to be used by many customers, yet each customer has complete control over what appears to be their personal server. Yes, you enjoy root level access. Only in reality, the machine is still shared with others. This option costs more than virtual hosting, but costs far less than a dedicated server.

Of course, a virtual private server is subject to the same laws of economics that affect virtual hosting. Too many customers on the same machine are going to slow things down. Performance is still constrained by available CPU, memory and disk space. In addition, running virtual server software takes additional system resources. The difference is that, in theory at least, I can avoid white screens of death by restarting my virtual web server to give it a higher timeout value. When traffic is high my users may have to wait a little while longer, but the web page should eventually come back to them.

I contracted with westhost.com, but wisely chose a one-year contract. As I am discovering there are other downsides to virtual private servers. For one, the control panel is a lot more elementary than other control panels I was used to, like cpanel. For example, there is no web application to help program cron jobs. (Cron is an operating system utility that allows you to schedule programs to run at certain times of day automatically.) You have to program cron jobs the old-fashioned way: from the command line. At the moment, this is a problem, since this version of cron does not like commands more than 80 characters in length. On the other hand, it is neat to do things like create as many databases on the fly as I like and install any application I want. It is also neat to turn on and off my virtual server, as well as to have real root access.

In short, at least for the moment, those with needs that are more specialized but without deep pockets should consider virtual private servers. In addition, only those who are not afraid to get their hands dirty with Linux should embrace them. I have some of these skills, but could certainly use more. As a professional IT manager, I have staff to do these things for me. Doing it by myself on the side is certainly educational. It gives me an appreciation for what my hard working staff does for me.

It is still a pain to transfer domains, although somewhat less so than it has been. phpMyAdmin creates a nice dump of the database for relocation, but the version on my new host has a 2MB file import limitation. This means to load the data I must run MySQL from the command line.

Dynamic applications are still a pain to rehost, particularly if you have customized them. It still means tar-ring and gzip-ping their files, moving them from machine to machine using FTP, then gunzip-ping and untar-ring them into the right directories. New database instances must be set up and populated. Configuration files must be tweaked. Moreover, all the ancillary third party software used by the application has to be set up again. In this case, I had to install a new instance of phpAdsNew, transfer my advertising database and carefully set it up. When all this is done then you also need to point the domain to the new host, which means your users have to wait while your change propagates across the Internet.

I am still a bit leery about virtual servers. Anything that sounds too good to be true probably is. In addition to being more flexible, virtual private servers also have some great security advantages. For example, there is no way a virus on my server can infect someone else on the same machine, because virtualization technology creates an impenetrable firewall between my virtual world and others. If my virtual server crashes, it does not affect others on the same machine.

Fortunately, I have 30 days to put westhost.com through its paces. If it does not meet my needs, I can get my money back and I still have time to host somewhere else. I can also choose to extend my contract with site5.com and put up with their virtual hosting annoyances.

There is a variant of virtual private servers called virtual dedicated servers. Most web hosts selling VDSes are actually selling VPSes. However, a true VDS will actually ensure that you get your fair share of system resources. That may be my next step if a VPS does not work out. Naturally, a true VDS costs more than a VPS, and so far, sticker shock is keeping me away.

I have two more domains to move over to westhost.com, including this blog. I hope to do it slowly over the next few weeks as I feel more comfortable navigating in this new and strange VPS world.

My thanks to my friend Jim Goldbloom (who also runs this nifty phpBB forum) for helping me sort through this confusing VPS and VDS world.