Stephen Skory

A week ago I saw a posting on digg about how Dreamhost sucks. It got me thinking about the problems I’ve been having with my account with Site5. Let me say that at no point has my experience been anywhere as bad as the one described in that link.

My hosting plan is on a shared webserver. Here is an informative page about my machine, named iaso. It has four Intel 2.8Ghz Xeon processors, and four gigabytes of RAM. It runs Linux which is a solid server OS.

My big problem are periods when this very website is unresponsive. There are lots of other websites on the same computer. And by lots I mean on the order of 600 websites:


-bash-3.00$ cat /etc/passwd | grep -v nologin | wc -l
646

The number of users with logins is not a one to one list of websites served, but it’s probably a good estimate. All it takes is one of the 600 users with a bad webpage to clog up the machine.

Below is a plot of the load level for iaso over the course of 15 days last month. Without going into specifics, a load level of one means that there is one process needing a processor at any given moment. It will be many different processes, and that’s fine. Practically, a machine can stay responsive with up to about a load of three or four per processor. So, on a four processor machine like iaso, a load level of 10-15 is about the highest comfortable level.

What you see above are many occasions when iaso went well above load levels of 25. The highest peak was a load of 230. In my experience, once the load reaches 25 my website becomes more than slow: it doesn’t work anymore.

For comparison, below is a plot of the same thing on one of the nodes of the supercomputer I use, Datastar. This is the node where scientists do heavy-duty analysis on their datasets. For instance, I use this node to process my multi-gigabyte datasets using IDL. People also run Mathematica and other very computationally intensive tasks on this machine. It’s got 32 1.7Ghz Power4 processors and 256GB of RAM (what do you have on your workstation, huh?). It runs IBMs AIX 5.3. As you can see below, for the first four days, the load level stays below one process per processor. In the fifth day something happens and it goes above 60 for a while, before the machine gets rebooted and things return to normal.

The kind of processes that run on the two computers above are very different. However, the supercomputer is supposed to run big jobs and get beat on. A webserver isn’t. Anytime the webserver’s load goes above 25, it’s like the supercomputer’s load shooting to 256. At no time did the supercomputer shoot to 256, while the webserver goes above 25 many times. Of course, I’m comparing 15 days to 5 days in the two plots, but I think the differences are clear.

Site5 pays a third party to monitor their webservers, with results listed here. iaso has 99.8% uptime overall and 99.4% over the last month. This is bad enough that apparently I’m due a 5% credit on my next billing cycle. iaso isn’t even living up to Site5′s own service standards.

Every time I catch my website being slow, I contact Site5 tech support. I know that this is a common problem with shared hosting. I’m sure that Site5 is aware that these outages, and does what they can when they happen. But, when it does happen, it’s annoying. It shouldn’t happen in the first place. Sometime this summer, Site5 is changing their hosting solution which may help with these problems. We’ll see.

For some reason, lately when I go to Yahoo! Mail (mail.yahoo.com), occasionally instead of going to my inbox, I get a page of raw PHP. Here are the first few lines:


<?PHP
ini_set('display_errors', 0);
$data = yahoo_reg_login_setup();

if ( $data === FALSE )
{
exit();
}
else if ( ! isset( $data['DISPLAY_FORM'] ) )
{
error_log( "yahoo_reg_login_setup didn't set the DISPLAY_FORM field" );
header( "Location: http://login.yahoo.com/");
exit();
}


Here is the rest of the PHP code. It is obviously the PHP code that runs the base of Yahoo! Mail, which decides where to forward you: either to your inbox or to a login page. At any rate, there's no reason why Yahoo! Mail's servers should be sending me raw PHP.

When I get this page, if I hit 'refresh' I'll get the correct page, so things aren't totally broken. This slightly annoying, and it's obviously a problem with Yahoo! Mail's servers. My web browser is incapable of producing raw PHP code, much less with a Yahoo! Mail bug tracking number (see the full text).

Trying to be proactive, I sent this code to their help department. I also wrote "Please don't tell me it's my problem, as there is no way my browser can generate raw PHP." They wrote back telling me:

We understand that you're receiving a HTML error message in your account ... To help us troubleshoot and assess the issue, please take a screenshot of the entire page when the issue occurs next.

They then proceed with instructions on how to take screenshots in Windows. As a Mac OS X user, I found this help insulting and useless. I am no common Windows user, and they shouldn't assume I am. Furthermore, providing a screenshot is even less helpful than my original post, as the PHP code covers more than one contiguous window - I have to scroll to see all the PHP code. It's clear that either my message wasn't read, or the person reading it had no idea what I was saying and put in the most general pre-written reply they could find.

It says something about your company when this kind of 'help' is allowed. This person should have forwarded my message to someone who had a clue. They shouldn't have sent me anything, much less nonsense, when they no idea what I was writing about. Perhaps there is no conduit for this kind of thing between the Yahoo! Mail help staff and the actual programmers. If that's the case, it's a shame, and it's more evidence why GOOG is kicking YHOO's butt.