Learning Center
Web Hosts
Nothing is unlimited, especially when it comes to bandwidth and disk space.
Take a step back and determine your hosting needs: think about what's critical, what's a "good to have" and what's "gravy on the side."
When it comes to choosing a web host, your major concerts should be: 1) reliability and speed, 2) customer and technical support, 3) creditability and 4) scalability and portability.
Reliability is critical, as you need to know that your website is accessible whenever a visitor wishes to pay a visit. Competitive pressures can drive a hosting provider to make unrealistic uptime promises - 100% uptime.
When a host advertises a 99.99% uptime, this gives them a cushion of about 53 minutes of outage time a year. This covers server down time due to regular scheduled maintenance and other unexpected disasters, such as denial of service attacks or overly popular websites that overload the server. The higher the advertised uptime, the narrower the margin for error and disasters a host has allowed itself.
We all know that Internet connections do go down, and websites do become temporarily unavailable for all sorts of intentional and unpreventable reasons. If your host advertises a 100% uptime, you may want to ask them about the measures they have taken to guarantee such an uptime. Their answer should including the following terminology: fully redundancy, mirroring, disk arrays, climate control, system administrators, uninterruptible power supply, etc. But still, keep in mind that there is no such thing as 100% uptime.
- What is their response time?
- How knowledgeable is their staff?
- Do they offer more than one communication channels?
- Do they have a support hotline?
- Do they have an online library or knowledge base where you can access tutorials, help files and other supplementary material?
Is it easy to switch hosts? Be wary about a single hosting package that offers you everything, from ASP to SSI. Very frequently, to have all these technologies running on a single box, the server will have many workaround configurations and security holes. Running a script in such environment will require you to modify your code with workarounds to match those on the server. The real problem arises when there comes a time you need to switch hosts and you realized none of your scripts work on the new servers, because the new server has their different workaround configurations.