DarrenL

I wouldn't say that at all - that is an incredibly blinkered view. In some cases a virtual server can be a sideways step - largely due to the fact that a virtual server with 512MB-2GB of RAM has much less headroom to cope with large influxes or traffic than a decent provider's shared hosting system (we use 24GB of RAM, for instance...) That said, a virtual server does allow some very specific optimisations in a system which otherwise wouldn't be possible on shared hosting. Apache with PHP running as DSO with opcode caching is not possible (or rather, advisable) on shared hosting - but the performance benefit (*especially* for Magento) is massive compared to suPHP and no op-code caching on shared hosting. It also means you can tweak Apache, MySQL and other higher level options specific to your website rather than running a "jack of all trades" configuration that is normally required on a shared system.

You say that as if they're small issues? Customer service and fast servers based in the UK are the difference between a good quality host (and some might even say ranking well in Google, nowadays) and a mediocre host. They're not absolutely terrible by any means, and get the job done for a lot of people - but there is much better out there.

99.9% allows for up to ~44 minutes in any monthy. So 99.95% is actually a quarter of that - so 11 minutes in a month. How much are you paying for your hosting? As long as the performance is good, 11 minutes in a month isn't bad and is largely better than a lot of "corporate" sites. The key thing with a business is to calculate the loss of revenue (or the cost in lost productivity) that those minutes of downtime give you. If the loss of revenue is greater than increasing your hosting budget and increasing the redundancy in your hosted systems, then upgrade.

Those are some very arbitrary requirements you've listed there. Whilst I agree with making sure that they're a real business (i.e. not a "one man band") the other points are arbitrary and largely depend on a user's requirements. For instance, I could recommend that you don't choose a hosting company that doesn't have its own AS#, and someone else could come along and say only choose a hosting company that has their own datacentre. Those things are largely irrelevant to the quality of service offered, and that is the absolute most important thing over and above any of these other arbitrary, largely ancillary requirements. The key thing is to research your prospective hosting providers - search for reviews. Sometimes not being able to find anything at all is worse than finding bad reviews since it may mean the company is new, for instance.

Wow, what a ridiculous generalisation. Some VPS solutions can be worse than very good shared hosting, in that a good shared hosting server will likely have 16GB RAM+ and other equivalent hardware specifications, so allowing sites to 'burst', whereas a poorly set up VPS could easily fall over under a deluge of traffic. That said, this only applies to badly set up virtual dedicated servers. The power of a VPS/VDS is in the configurability of the system, such that you can tweak your web server (not necessarily Apache), MySQL, PHP configurations (e.g. opcode caching) in order to get the best performance possible for your site. You can also set up things like memcached instances on your VPS/VDS to improve performance further. A good VPS/VDS can easily be better that a low end dedicated server in many respects - including performance but not least redundancy and reliability.

http://hosting.peartreeuk.com/ is working here - perhaps you've been blocked at their firewall for some reason? Give them a call/email.

We host one of the main political party's manifestos as well as a number of videos and other high bandwidth items. The important thing is to make sure you go with a host that when you purchase x amount of disk space or bandwidth, you know that you're going to be allowed to use it without fear of being cut-off mid-way through a marketing campaign or similar. ^Peartree's suggestion of a CDN is also very good - it means if you have a geographically dispersed target audience all across the world, they should all experience fast download speeds.

For Coldfusion, you'll probably want to look at a virtual server (VPS). You might also want to take a look at Railo as a free CFML alternative - http://www.getrailo.com/

How about this one? http://to./ ;p The registry for Tobago have obviously entered a record at the DNS root for .to. Nice URL though.

If you don't have any DNS redundancy, when your main server is ever down email will be lost for the length of time that the server is down. So if you ever need to reboot, or rebuild a kernel - or if your provider has a network issue, mail sent to your domain will be bounced. Mail servers will retry sending every few hours for hosts where the MX is down, but if they can't get to the DNS servers they will assume the domain is dead and not even bother sending (the sender will get a bounce). A backup nameserver should always be a consideration. If you haven't got a backup nameserver, consider using an externally hosted DNS service for your most important domains/websites.

It's only a provider's fault if they fail to act once notified. On shared hosting systems, this can be an all too common occurrence, especially with the prevalence of easy installers for scripts like PHPBB, Wordpress, Joomla etc, as well as people playing at developing their own contact form... it only takes a small vulnerability for a spammer to compromise the script and send thousands of messages in a short time. The only way to ensure absolute email deliverability is to go for a dedicated hosting solution - either virtual dedicated or hardware dedicated. This means that the only person that can affect your email sending reputation will be you. One other problem often encountered is that users will forward their messages to their own Hotmail, Yahoo or AOL account. When a user then receives spam via that forwarder (or sometimes even legitimate messages!) they then mark the message as spam via Hotmail/Yahoo/AOL's system and their system incorrectly determines the forwarding server as the source of the spam. We've had to seriously consider whether we will allow users to continue forwarding to these addresses as it is causing a lot of problems for other users on the system. As said, some users even mark legitimate messages as spam, which can be even more troublesome.

With this amount of traffic a shared hosting solution is really not suitable - you'll want to go for a dedicated, or a VPS at an absolute minimum. Ideally, you would encode any uploaded videos in the background - *not* on the server that you run your main front end website(s) on. This prevents any slow downs or poor performance due to the CPU usage of the encoding.

Gotta agree with Wesh here, the US hosting market is very different to the UK market. Very few quality US hosts remain, most of them having been swept under by the likes of Dreamhost, Hostgator, Hostmonster who offer ridiculous packages for low prices (as long as you pay 3 years up front ). If you just need a small space to host a few hobby websites, then those guys mentioned above are pretty good, they'll get the job done for the most part. However, if you have a serious site, or a business site - a UK based hosting company which you can call and resolve issues, with UK based servers so that your site is more responsive to your local users will ultimately be important to a lot of people.

I'd recommend trying to contact Othello directly and attempting to resolve the issues before moving away which could cause more downtime. Rob (the owner of Othello) posts on www.webhostchat.co.uk regularly if you want to get his attention.

Sounds like a Twitter feed scraper or similar. Efficient database storage and design will be very important for this project. We were working with a client recently that had to index/store 300GB of data in a MySQL database - it wasn't pretty. What I would recommend is possibly creating a table for each x number of entries (say, every 250,000). This way, when you do an insert or update, only the table upon which you are inserting or updating requires a lock. You could take this further, depending on how relational the database needs to be and use a separate database for different "blocks" of data. This will help the scalability of your system immensely.