Moving web hosts, from the frying pan, into the Arvixe fire

A few weeks ago, I finally bit the bullet and moved our marketing website to a US hosting provider. There were lots of reasons for making the move, not the least of which is that more than half of our new signups are coming from the US, a market that is used to very low latency connections. Crossing the Pacific to get to our (at the time) Australian shared host wasn’t good enough.

Our requirements were pretty run of the mill – the new host needed to support PHP 5.2 and MySQL so we could run SilverStripe, the CMS we use to drive our marketing website. While our engineers spend their time and energy working on the main AffinityLive product – which has nothing at all to do with our marketing website from a technical perspective – the fact our team are hard core meant that we also wanted to have SSH access and the ability to maintain our site using the technology all the cool kids use – no FTP for us.

Of course, going to Google and typing in “LAMP web hosting” is like going to Google and typing in “mortgage” – you get inundated with options, all of which make big claims and look much the same. The things you care about the most are the quality of the human support, that the hosting company supports the technology you’re using “out of the box”, and that they don’t cost you the earth.

I got in touch with one of my friends who’s a founder at SilverStripe, and asked him if there were any web hosts out there that he knew of which make an effort to specialise or fit in with the SilverStripe CMS. You know, that have the right PHP modules ready to go, that keep PHP up to date but not too bleeding edge, etc. He told me he couldn’t recommend anyone, but one of their partners who were doing good things was Arvixe. As anyone who faces a daunting comparison process of a thousand options knows, being suggested to “just do this” is a godsend.

Knowing that human tech competence in support is the hardest thing for a hosting company to get right – anyone can rent racks and install the standard kit on them – I started to ask a bunch of pre-sales questions using the online support directly from the homepage of Arvixe. The support was prompt and knowledgeable. This was on a Saturday in the early afternoon in California – not the graveyard shift, but close to it. I was impressed.

Live chat based support was easy to find and very high quality

So, I pulled the trigger, signed up, and got underway.

The whole process was pretty good. The cPanel did things a bit differently, but again, the live support was great. I migrated the site across with a mixture of SVN and Rsync; the only small hiccup was their version of SVN not supporting svn:externals that were located on an SSL host. Not a huge deal, and before long I had, and migrated across to the new hosting platform.

Then the trouble began.

My staff started to complain that logging in to update the site was proving really flaky. The site would appear “down” or offline quite a bit. Updating our blog with the weekly updates on the new version of AffinityLive being pushed proved very frustrating. Initially I thought it might have been the change of hosting to the other side of the pacific from what the office team in Australia were used to, but Hugh, who’s our only non-developer on the staff set up a trial account with WebSite Pulse, which showed clear problems.

I then set up monitoring with the main outfit we use to monitor all of our other AffinityLive platforms,, and was horrified by what I saw.

Wormly was reporting errors – such as packet loss on pings, or timeouts on loading the homepage – of more than 97%! (see Tuesday 22nd of September).

Now, I knew that I was on a cheap shared hosting plan. I wasn’t expecting 99.999% uptime and for the system to be bulletproof, but I was expecting it to work most of the time.

I really didn’t want to go through the process of moving servers again. So, I called the sales office at Arvixe on the 20th of September, and explained the problems I was experiencing. I had details of packet loss, the load the server was under when I was occassionally able to log in via SSH (15 minute load was above 3).

The guy from the sales team told me that this was not uncommon, because new users get put on new servers, and a decent percentage of new users are actually abusers who they need to weed out and remove as clients. He offered to move me to a different underlying host, and I said, “Sure, I’ll do anything, I’ll pay a bunch more if I’m on a class of plan that is too low – I just need this to be fixed.”

From here, I got into a week long debate with their tech support team. They wanted evidence of the packet loss reports, which I sent them. They then told me they couldn’t read them, probably because their helpdesk software strips all formatting from emails. Then I provided attached reports in CSV format and a bunch more info. Remember, this is at a time when they said they’d just move my account to a different server. I’ve already told them I’d pay more to go up a tier. And instead of just making it happen, they were having an argument and were then technically unable to listen to my comments on the other side of the debate.

After suffering through this problem for more than 10 days across two continents, I finally got the time on the ground early last week to up and move hosting companies. I’ve selected Dreamhost, and so far things are going really well. Of course, the process of moving cost me a bunch of time and energy which I didn’t really have to spare – what with jetlag and making the best use of the face-time I have with my engineering team here in Australia – but on the 30th I managed to flick the switch across to Dreamhost. As you can see from the Wormly report dashboard above, we’ve had zero failures since moving the site to Dreamhost compared to when we were with Arvixe.

The sad thing is, I really wanted to like Arvixe. Their people were friendly and professional and delivered a great human service, usually the hardest thing to do in a tech business. But, their core product was just so completely horrible and terrible that I just couldn’t stick with them, which is a real shame. Hopefully they’ll get their act together in the future, but in the mean time, if you’re using SilverStripe, I’d suggest you go with Dreamhost.

6 thoughts on “Moving web hosts, from the frying pan, into the Arvixe fire

  1. No offense, but this makes you sound amateur, not the hosting company. I am a twenty year old University student and when we had to setup hosting for our tiny project we setup live instances at three different providers (EC2, Rackspace Cloud and dotcloud), benchmarked them and then switched over to EC2. Switching over what is your business website without first testing the provider is your own fault. We are just running a small part-time project, and you are supposed to be some sort of expert?

  2. Fair point Greg; I was in a rush unfortunately, and wanted something off the shelf. Our main infrastructure for the product, however, took a LOT of work and testing over a 9 month period to put into production.

  3. Hello,

    I’m sorry for your issues. Per my research, it appears that you were on the ostrich server. I can assure you that at Arvixe, large server side issues reach management very quickly. Some are easy to resolve and some take time. Whether at Arvixe, Dreamhost, Bluehost, etc. you are being placed on a single server out of hundreds or thousands under management. Your experience with that specific company’s hosting services is summed up by not only their ability to properly manage the servers but also other customers’ level of activity on the specific server.

    I can agree with you that Ostrich has had some minor issues within the past week or so in regards to slower PHP processing. However, I would ask you to be reasonable in your assessment that a we had a server down for 5 days straight. The entire output looks a bit off when you have 5 days with literally no uptime (which has never happened in the history of Arvixe).

    I’m attaching an uptime report for that server for the past 31 days. The uptime report uses the Nagios monitoring system setup in Seattle to ping the server every minute. This certainly only checks for the server’s uptime. But for any monitoring system to be accurate, it needs to do not only minute by minute monitoring but also outline exactly what is being checked. Is the HTTP status code being checked? IF so, which status codes outline downtime and which status codes outline uptime? Or is it just ping? Do you know for a fact your monitoring system does minute by minute monitoring? Also, heavy access to the server can be considered abusive by the server firewall and therefore, the monitoring system could get blocked causing the monitoring system to show the extended downtime you are seeing.

    To date, out of ~300 servers under management, not a single server has exhibited the level downtime shown in your report. I would welcome you to take a free account from me on a different server (or the same) and use a variety of monitoring services to monitor the service so that at the very least, you are left with a neutral feeling towards our services. I have no doubt that we’ll be able to change your mind. And I can assure you that if you did end up on a poorly performing server on dreamhost and placed a post or blog post on the internet, you would not have someone from their management approaching you this quickly which I hope spreaks a bit to our concern for quality and excellence.

    The screenshot mentioned above is available here: What I believe is the most important is the average uptime of a host’s servers across a large number of different accounts and servers. There is one site that does a good job of taking each host’s customers’ domains when they leave a review and monitoring them to come up with an aggregated uptime report. That is available here:

    • Thanks Arvand, I really wanted to stick with it and Arvixe. The reports from Wormly were based on pings, and allowed for 50% packet loss. The http requests had relatively short timeouts, and were being tripped up a lot too. “top” on the servers was very very high, a lot. Basically, the shared environment was being pounded, and we needed, pleaded, and were prepared to pay to get out of there and stick with Arvixe.

      I was happy to pay more and move servers inside your network and remain a happy customer – as I said, high quality human service is really hard to get. But, instead I spent 10 days being expected to prove the problem, which you’ve acknowledged was a problem, and ended up having to make a move I didn’t want to make. While averages across all hosts is a sensible way to compare brands, when you’re on a server which is a dog asking to move/upgrade in the company is ignored, you don’t have much of a choice.

  4. Good to meet you briefly the other morning mate, I will be back in the valley in the next 6 weeks – I am diligently following your advice on setting up a US company and sponsoring myself. I’d like to talk to you more about Affinity Live – maybe this aint the right forum … however bust me an email and let’s converse.

    Re: Hosting – I use the Rackspace Cloud servers and have absolutely zero problems so far – I used to use Intermedia, but having a virtual box I can manage as root and SSH to makes all the difference. I rarely use the control panel as i can just SSH to the box – they are using XEN virtualisation I believe and they can upgrade your virtual boxes memory or give you a dedicated box and mount your drive in minutes (so they say) – our footprint is Redhat Linux, Postgres, Perl and Apache – We use a lot of sendmail and the reverse DNS is easy to setup. Just my two cents worth.


  5. Arvixe sucks period.

    Greg you are a dick, because irrespective you dont learn the nuances of how a company will support you. Its pretty easy to say in hindsight “do your research” and that maybe true but it doesn’t hide the fact the company cant be trusted.

    Rest have a good day !

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s