Posted on June 13, 2009 - by Venik

Bluehost.com Web Hosting Problems

Bluehost.com is a large Web hosting provider based in Provo, Utah. It advertises “professional Web hosting” and claims to be “specializing in customer satisfaction”. Yesterday I learned neither of these claims is true. Originally, I selected Bluehost.com over my other top picks – Site5.com, Hostway.com, and my own old Sun E3000 server sitting in the basement – because it was listed as an approved provider on the WordPress site. WordPress, of course, is the hugely popular open-source blogging software that I am using. The initial setup was relatively painless and my site was up for a few months without major problems. It should be mentioned, however, that Bluehost’s claim of 99.99% uptime (about an hour of downtime per year) is exaggerated. You see, server uptime is not the same as your Web site uptime. A server can be “up”, but it may be experiencing various problems that prevent your site from functioning properly. Even so, the actual uptime of “box468″ server that hosts my site is no more than 99.5% (about 4.5 hours of downtime) based on the past five months of monitoring using GoStats.com service. My site consists of standard WordPress with a few popular plugins – nothing fancy. The amount of visitors is not high and would not stress even the most modest server. Something was going on with the Bluehost server yesterday and a few SQL queries started by WordPress took 4 seconds to complete. Bluehost claims that any SQL query taking more than 2 seconds to run is a problem. And so they disabled my account and sent me the following email:

Your web hosting account for venik4.com has been deactivated (reason: site causing performance problems). Although your web site has been disabled, your data may still be available for up to 15 days, after which it will be deleted. If you feel this deactivation is in error, please contact customer support as soon as possible. Thank you, BlueHost.Com Support

Short and sweet – typical sysadmin social skills at work. I should know for this is exactly how I treat my clients. And so I responded along the same lines demanding my account to be reactivated. There is not much else I could do to fix the problem – whatever it might have been – without having any access to the system or to my site. Half an hour later Bluehost replied:

You will need to review your cpu_exceeded_logs & mysql_slow_queries log. <snipped: a long-winded explanation on how to find and access the logs> How to Ready the Logs:  The first line will be the date & time the log was taken. Query_time: this is how long it took the query to run (anything over 2 seconds is bad). Rows_examined: this shows how many rows were examined in the time. Use or User: this will tell you what data base or data base user that was being called in the query. This information will help you in narrowing down what the issue is on the account so that you can resolve it. Abuse Department 1958 South 950 East Provo, UT 84606

To most non-technical clients this would be an almost incomprehensible gibberish. To me it was a clear indication that Bluehost was trying to shift the blame for their server’s poor performance to their customers. You see, the 2-second cap established by Bluehost is an entirely arbitrary value that has no significance. A SQL query may take a second or an hour – everything depends on how the query is written, how much data it is trying to access, performance of the server, and network conditions (in case of servers using NAS). Since all my SQL scripts come from the standard WordPress installation, which Bluehost claims to support, and the database is in order, there should be no performance problems. Unless, of course, the server is overloaded because greedy Bluehost put more users on the system than it can reasonably accommodate.

I reviewed the logs suggested by Bluehost support and found nothing out of the ordinary. I informed “Carl” (who sounded more like a Manish or Amit) of Bluehost support of the results of my expedition into the depths of their SQL performance logging mechanism and suggested that, based on my fifteen-year Unix sysadmin experience, the problem seems to be with their server. Like, for example, average system load of 10 I was seeing on the server was more than twice what would be considered the critical threshold. “Carl” was not satisfied and responded with the following impressive technical analysis worthy of the most experienced gas station attendant:

Thank you for contacting our Abuse Department. Did you review your logs? This issue is not indicative of the ’server’ itself having performance issue. It’s your scripts and/or databases which cause it. Failure to keep your scripts up-to-date with the latest development releases and/or keeping your databases repaired and optimized can cause these issues from YOUR account. In deactivating your account a significant increase in server performance was noticed. Please refer to your logs to see which database and/or script had gone a rye. You have several slow queries reported for the following: # Thu Jun 11 03:00:14 2009 # Query_time: 4 Lock_time: 0  Rows_sent: 0  Rows_examined: 0 use venik_blog; SELECT SQL_CALC_FOUND_ROWS distinct blog_posts.* FROM blog_posts  WHERE 1=1  AND YEAR(blog_posts.post_date)=’2009′ AND blog_posts.post_type = ‘post’ AND (blog_posts.post_status = ‘publish’)  ORDER BY blog_posts.post_date DESC LIMIT 0, 14 # Thu Jun 11 03:00:14 2009 # Query_time: 4 Lock_time: 0  Rows_sent: 0  Rows_examined: 0 SELECT SQL_CALC_FOUND_ROWS distinct blog_posts.* FROM blog_posts  WHERE 1=1  AND YEAR(blog_posts.post_date)=’2009′ AND MONTH(blog_posts.post_date)=’4′ AND blog_posts.post_type = ‘post’ AND (blog_posts.post_status = ‘publish’)  ORDER BY blog_posts.post_date DESC LIMIT 0, 14 Please refer to your MySQL Slow Queries log and rectify the issue then notify us with a brief description of what you’ve done in order to get your services reinstated. Thank you, Abuse Department 1958 South 950 East Provo, UT 84606

It would seem “Carl” was under the impression that a  malicious SQL “script had gone a rye” – that is turned itself into the seed of a cereal grass and was rampaging through the neatly trimmed lawn of his server. Realizing that any attempt to argue with this guru of Web servers was a waste of my time, I told him that I optimized the database and from now on everything will be running smoothly. Patel, I mean “Carl”, graciously agreed to reactivate my account. And so here I am blasting Bluehost on their own server. I told “Carl” that, in my humble opinion, Bluehost was in violation of Paragraph 7.1 of its own ToS:

7. “UNLIMITED” USAGE POLICIES AND DEFINITIONS 1. What “Unlimited” means. BlueHost.Com does not set an arbitrary limit or cap on the amount of resources a single Subscriber can use. In good faith and subject to these Terms, BlueHost.Com makes every commercially reasonable effort to provide its Subscribers with all the storage and bandwidth resources needed to power their web sites successfully

Call me crazy, but a 2-second limit on SQL queries sounds like an arbitrary cap. It would certainly be nice if all SQL queries completed in under two seconds, but Bluehost would have to spend millions on upgrades to make this happen. I emailed “Carl” my thoughts:

While I appreciate your quick response, I am not happy with my account being disabled in the first place. All I have is a standard WP blog – a small database and very few visitors. A careful review of Bluehost’s ToC leaves little doubt that the decision to suspend my account was in breach of paragraph seven. I need to be sure that Bluehost is a stable hosting provider and that this incident was an aberration. Please let me know how I can contact Bluehost management to discuss this issue further.

But my friend “Carl” wasn’t born yesterday and skillfully evaded my request:

Hello, Thank you for contacting our Abuse Department. You are part of a shared hosting environment, meaning you share the server space with hundreds of other users. When 1 account is causing issues for hundreds of other users on the server we cannot give you time to fix the issue while other users suffer. Thank you and have a good day. Abuse Department 1958 South 950 East Provo, UT 84606

We exchanged a few more emails along the same lines and I eventually dropped the matter. Well, almost: being the jerk that I am I did file a BBB complaint and sent a “breach of contract” grievance to Utah’s Attorney General’s office. I also sent a “false advertising” complaint Utah’s Division of Consumer Protection. There is a Russian joke about a rooster chasing a hen, thinking to himself: even if I don’t catch her, at least I’ll keep warm. As I am writing this post, Bluehost’s main site is down. So much for the 99.99% uptime claim.

Bluehost is down on June 13, 2009 at 6:50pm EST

Update:

Below are two screenshots showing system load on Bluehost and Site5. Despite having twice the amount of RAM and faster CPUs, this Bluehost server is struggling with the average sustained system load (see top line) of around 7. As a Sr. Unix System Architect for a Fortune 50 company, I can tell you that once the sustained system load on a Web server exceeds 3, it is time to start thinking about an upgrade.

The Site5 server is running at well below 0.5 system load. Looking at the screenshots, you will also notice the uptime of the two servers: Bluehost – 1 day, Site5 – over a week since last reboot. Bluehost is forced to reboot their server almost every day because its is severely overloaded. Since this server is not part of a high-availability cluster, every reboot means downtime for your site. This makes Bluehost’s claim of 99.99% uptime one giant ass sneeze.

Join the forum discussion on this post - (1) Posts

Related posts:

1. Novaya Gazeta and DDOS Attack
2. My Verizon FiOS Experience
3. Verizon FiOS is still too green. I am back with Comcast.