Just over a month ago now, we launched a pair of commercial WordPress websites for a local business initially using a top-end “dual hosted” Business plan provided by 1&1.

We went this route for a number of reasons, one being the significant amount of advertising 1&1 seem to produce (applying the “they can’t be that bad” concept), and the second was a desire in the current commercial climate to try and reduce the operational cost around web hosting.

The new sites were to replace two 4-5 year old sites running on a Windows 2008 VPS provided by Tagadab, which with all credit to Tagadab has been an extremely reliable box for the year it’s been in use. One of the key drivers behind relaunching the sites however was to migrate to an open-source CMS environment which could run on a wider range of platforms rather than just Windows & SQL Server; allowing us to migrate onto commodity hosting and take full advantage of high performance alternative webservers to IIS such as Nginx.

Shortly after the new sites went live on 1&1, we realised that our choice of host was actually a massive mistake as we weren’t getting anywhere remotely close to the levels of reliability, performance or support we needed and decided to plan a controlled move to a more professional service from MediaTemple (mt).

During another prolonged 1&1 outage, the idea of planning the process soon disappeared out of the window along with our websites & in the space of an hour or so we moved over to (mt)’s Grid Service & cut our losses with 1&1. We’d opted for (mt) as following some great feedback from other businesses (gs) sounded ideal. After a couple of weeks however, it became somewhat apparent however that although they consistently delivered great levels of reliability along with good support, performance on (gs) for UK visitors simply wasn’t anything close to as good as we either expected or needed. Some investigation into this suggests that the basic problem was the lack of database responsiveness, something that could have probably been resolved by upgrading the account to use a dedicated MySQL container rather than the standard (gs) platform. If that didn’t deliver, the next step was to upgrade to (mt)’s Dedicated Virtual (dv)  VPS platform, which is essentially an expensive / somewhat overpriced VPS solution.

The chart below shows average response times for one of the sites from September to November 2011, which while rather illustrating the issues we encountered, actually hides the worst aspects behind the averages. At its peak, the site took something in the region of 4-5 seconds per page load with (mt) and 3-4s for 1&1.

Before embarking on this “adventure” we’d previously been accustomed to sub-second page loads with the old site and although we were not expecting a more complex WordPress site to deliver the same level of performance, needed something significantly better than 5s per page.

Opting for the quickest route to getting a working platform, we subsequently decided to return to the VPS route to ring-fence resources for our sites, and began looking around for a reliable UK based hosting company offering a fast VPS provisioned on the XEN virtualisation platform (XEN, OpenVz, VMWare etc are all different virtualisation technologies with XEN often offering faster VPSs as it can help prevent unscrupulous hosts from overselling their server capacities & overcommitting VPS resources).

Having signed up initially for a VPS in a large Netherlands datacentre, we started installing all the necessary software to run our sites opting for Nginx in place of Apache… which led to a raft of additional issues as we worked our way through numerous tutorials / guides in an attempt to find a set of recommendations or instructions with which to actually get everything working properly for WordPress; documenting the build as we went just in case we needed to do it again. Performance was great as you’d expect with Nginx running on a fast VPS with plenty of resources, but unfortunately after 6 network outages in the space of 7 days we discovered that our new host (or their datacentre) had a major issue with being on the receiving end of DDoS attacks.

Having planned ahead & documented the build process, moving the sites again (to another new VPS, this time UK hosted) took under 30 minutes from provisioning a new VPS to moving sites & DBs across, to being ready to go live.

We always use separate services for web, email & DNS so moving our websites around is a relatively simple exercise. If you can, keeping separation between key services is a great way forwards as it gives you significantly more flexibility than if you rely on one machine or host for everything!

I’ll share our build process in my next post, as a hopefully relatively foolproof guide for getting a freshly installed machine up and running with Nginx, PHP, PHP-FPM, MySQL & WordPress.

Coming back to the subject of this post, it just goes to demonstrate that the cost of a hosting solution is often far from the most important aspect in terms of deciding whether or not to use a particular hosting service. Cheap hosts are often a great demonstration of this as you never tend to get much in the way of server resources, support or performance – often making them far from a good option for running anything important. At the other end of the scale, more expensive hosts don’t always deliver either. Our DDoS-bound host for example offers a good range of VPSs from tiny to XXXL, costing between £2.99 & £40/month. Not top-end pricing by any means, but for £40/month you tend to expect a reliable solution which remains online…

In summary, finding a good host is not a simple process. It’s something you can ease a little by checking out your prospective hosts before signing up (as a tip, search for your host’s name on the WebHostingTalk forums), but unless you have a cast-iron recommendation from someone you trust or other reasons for believing that your next host is it for a long time, it’s worth sticking to a few guidelines:

1. Know what you want in terms of server location, hosting type, disk space, bandwidth, CPU resource & server software etc.
2. Shop around – Google for the type of hosting you’re looking for and see what’s out there.
3. Search for independent reviews & recommendations on sites such as WebHostingTalk.com & try and ignore the many “everything’s perfect” type paid-for reviews if you can’t find anything positive on WHT. Don’t be afraid to ask whether anyone’s used a particular host if you can’t find anything.
4. Stay flexible – don’t tie yourself into long term 12, 18 or 24 month contracts as you can normally buy hosting services from reputable suppliers on rolling 30-day agreements. Be cautious if someone wants to tie you in for longer.
5. Don’t be afraid to switch hosts if you’re not getting the performance, reliability or support you need.
6. Finally, make sure you have a clear, documented set of instructions/notes for building your VPS from fresh OS install through to having sites online. Might seem overkill when you’re doing it for the first time, but rest assured it makes subsequent builds or rebuilds significantly easier!

For now, if you take nothing else away from this slightly rambling tale, it would be to try and stick to the above guidelines 🙂

Check back soon for that Nginx build guide!