 |
 |
|
|
||
Some site moves are planned, like our recent move. Others are suddenly forced upon the site owners, as happened to two of our clients. This article can help you plan an orderly move. It can also help you prepare for the eventuality of an emergency move. Two of our clients have needed to drop all other tasks to focus on moving their sites to another server at another hosting company with the utmost speed. One of our clients was given 4 days notice (hardly enough time to make the necessary DNS record changes, much less to shop for another hosting company; although their current hosting company kindly offered a high-priced server to accommodate their successful site and even offered a "reasonable" setup fee to move the client's site within the time limit imposed) and the other of our clients was given 7 days notice (which at least gave our client time to shop around). If the above paragraph was alarming, it was intended to be. In both cases, our clients had hosting accounts with no data transfer limits. But that's not what got them in trouble. It was the CPU usage. (CPU usage can be understood as the amount of time, usually measured in seconds or fractions of seconds, that the computer's Central Processing Unit is active to accomplish a given task.) How it could happen: The more sites a hosting company can pile into a server, the more money they make. Large hard drives are inexpensive, so one server has the potential of hosting many dozen or even hundreds of sites. That's all well and good, so long as all those sites are relatively quiescent. Even if each site recorded several hundred hits a day, the server would barely have been nudged. After all, it only takes a fraction of a second to serve a file. However, if some of those sites begin using ASP, CGI, PHP, or other CPU intensive technologies, the server will have a slightly bigger load. If some of those sites then become successful, the server could experience a heavy load — and every site on that server would experience a slowdown. Therefore, even if you have a hosting account with no data transfer limits, it would be prudent to find out whether or not your hosting company imposes limits on CPU usage — especially if you plan for your site to become ever more popular. In both our clients' cases, the hosting companies involved had CPU usage limits. But the information was buried within layers of links. One mentioned it in their Terms of Service, the other did not. The "no data transfer limit" was bandied about as a selling point, implying but not promising room for unlimited growth in site popularity. But the CPU usage limit, the thing that could really hurt a successful site, was not addressed or simply glossed over, and only brought forward as pertinent when it served the hosting company's interests. So write to your hosting company. Ask them for references to all material related to CPU usage that can pertain to your site. Ask them to inform you when any of that material changes and when other material is added. And if they do have CPU usage limits, ask them for a method you can employ to monitor your CPU usage; preferably a method that does not, of itself, count against your CPU usage limit. If your hosting company has no stated CPU usage limits, then re-read their Terms of Service and pay special attention to the conditions under which they can cancel your accounts. CPU usage is finite. When the server is busy, it's busy. Installing larger hard drives lets more sites be stuffed onto a server, but it does not make more CPU available. Therefore, hosting companies must be sensitive to that aspect of their servers. One very successful site causing a dramatic server slowdown can create many unhappy customers for the hosting company to deal with. Preparing for a move: Preparing for an orderly move and preparing for the eventuality of an emergency move involve the same one step: Maintain an accurate mirror of your site. This means you download your entire site either on a regular schedule (if your site has self-updating pages or databases) or whenever you make changes. This mirror can be compressed to use less space and/or copied onto backup disks. When you have an accurate mirror of your site, you can move your site even if you lose contact with your current server. Although an accurate mirror might not be necessary for every orderly move, it can serve as insurance against file loss or corruption during transfer from one server to another. Choosing a hosting company: Not always, but in general, you get what you pay for. Cheap hosting is usually exactly that. But expensive hosting does not necessarily mean the best. Consider the current size, technical requirements, and popularity of your site as well as those aspects projected a year or more into the future. If you have only a few CGI programs, a smallish site, and your site popularity is still somewhat low, then an inexpensive hosting solution might be sufficient for the time being. On the other hand, if you use a large number of CGI programs or other CPU intensive technologies and your site is popular or you expect your site to quickly become popular, then find a business solution at a hosting company that is lenient regarding CPU usage. Another thing to consider is the operating system of the server you're moving to. If you already use technologies requiring a specific server operating system, then you'll need to move to a compatible server. If your site is composed only of web pages then you have choice. With choice, I would recommend a UNIX flavor (BSDi, FreeBSD, Linux, NetBSD, SCO, etc.) operating system. I believe more servers use that type of operating system than use NT. Certainly, there seem to be many more free and good CGI scripts available for UNIX than for NT. We use http://www.iServer.com, the only hosting company we recommend because it is alone in consistently having met, and sometimes much exceeded, our expectations. Although we moved to a different server recently, we stayed with iServer.com; the move was to a server with mod_perl. Making the move: On thing that must be done is to update your domain name record to reflect the DNS of the new server. Your domain name record must be updated at the registrar where your domain name is registered. Used to be, the only internet domain registrar was networksolutions.com. Now there are others. If you don't know which registrar holds your domain name record, you can go to http://www.netnameone.com/ or most any other registrar and use their "whois" form to look up your domain name. The lookup details should show which registrar holds your domain name record. To change the DNS of your domain name record and have that change propagate to all ISPs and other internet data routing centers can take two to four days. If yours is an emergency move to be accomplished as soon as possible, change your domain name record first. Then upload and test your site. However, if you have plenty of time, upload and test your site before changing your domain name record. When we moved our site, it took almost three days for propagation to complete. Several people made ebooks on the old server, and came back later to pick it up only to find the ebook not available because they were now at the new server. And for a while we were receiving email at both servers, depending on where the email originated. To upload and test your site:
Moving a site need not be a stressful experience. It's fairly straightforward. If you take care of one glitch at a time, rather than trying to fix them all at once or allowing yourself to become distracted as others demand your attention, then the experience can be fun. May all your moves be smooth! Copyright 2000 William Bontrager
| ||