TroubleshootingLockups During File TransfersThe Situation:"My web site locks up completely from time to time, mostly when I'm publishing or FTPing updates to my site. How do I prevent this from happening?" Suggested Action:This problem can occur when FTP or FrontPage transfers fail to complete properly. Network problems, configuration issues, and unexpected power outages can all cause this kind of interruption. To alleviate the problem, try using the following methods: For FTP When sending updates to the web site, try not to overwrite existing files during the process. Instead, rename the target file (or files) to be replaced with some temporary name before uploading. For example, if index.asp and mybooklist.htm are going to be overwritten with newer files, rename the old files something like index.bak and mybooklist.bak. After successfully uploading the new files, the old ones can be deleted. This way if the upload hangs, the original files will still be intact. For FrontPage FrontPage users should make sure that their publishing sessions don't hang in the middle of the transfer, as this can cause the same problems as FTP breakdowns. Default Documents"I have an index.htm and an index.asp in my web, but when users try to access the site, their browser brings up the wrong page! I want the web server to deliver index.asp by default, not index.htm. What do I do?" Suggested Action:Since IIS (Internet Information Server) supports multiple default document names, having more than one document with one of those accepted names in a single directory confuses IIS. IIS remedies the situation by only displaying the first document it encounters with one of those accepted names. To fix the problem, make sure that the desired default document is the only document in its home directory that has a "default name." Other files with "default names" (default.htm, index.htm, index.asp, default.asp, index.html, etc.) should be renamed.
Valid default docuemnts are (in this order): default.asp, default.htm, default.html, index.asp, index.htm, index.html, home.asp, home.htm, home.html Site Deems SlowThe Problem: My web site is unusually slow. Before contacting technical support, try a couple of the procedures below: First, bring up a command prompt. In Windows NT, this can be accomplished by going to the "Start" button, then selecting "Run" and typing cmd. In Windows 95/98, there should be an "MS-DOS" icon for the command prompt option on your "Start" menu. Unix users can just use a shell session. Make sure you are connected to the Internet before performing this procedure.
C:\>ping www.hostingsupport.com Note the results marked time=XXms. Anything under 300 ms (milliseconds) is considered good on average.
C:\>ping www.hostingsupport.com.com -l 1500 Note the results marked time=XXms. Anything under 300 ms (milliseconds) is a good time. 1500 bytes is the size of a normal packet. If you were to see this: C:\>ping www.hostingsupport.com -l 1500 Then there may be a routing problem. To find out whether the problem is us or another company’s routers, do a tracert by typing tracert www.yourdomain.com. The results will look something like this: C:\>tracert www.hostingsupport.com These are excellent trace times. If you have trace times like these, then the problem is most likely the server. However, if you have trace times of 300 ms or greater, or if you see a "*" in place of a time, then the problem is not with the server, but with either a router you are going through or your dialup provider. Please note that the slower your connection is (14.4Kbps modem, 28.8KBps modem, etc.), the slower your initial trace times will be. These times should gradually average out later in the tracert. Bad tracert times are often the result of router problems at one or more of the ISPs (Internet Service Providers) that your network is attempting to send packets through. The "*" that appears in place of some times means that a router is dropping packets completely. As soon as a router drops a packet or slows down, the other routers "downstream" will appear slower or appear to drop packets, too. This chain reaction can be initiated by failing hardware, abnormally high network traffic, or both. Users with more than one Internet account will often notice that tracert results will look different on each machine they try. This phenomenon occurs because different Internet providers channel their packets through different routers. There is very little that can be done about this as each Internet provider is a self-regulating entity (the Internet is a non-homogenous network constructed from hundreds of thousands of participating providers). Poor routing in one area doesn't necessarily mean that everyone is experiencing the same problem. All companies route either through MAE-East or MAE-West. MAE-East/West are "gigaswitches" -- pieces of equipment that route enormous numbers of packets. If one of these gigaswitches fails, people all across the world experience slowdowns and outages as a result of the network traffic backlog. A company called Datametrics makes an especially useful visual tracert utility that users may wish to try. The tool is called VisualRoute, and it requires a working Java Virtual Machine to run. (Any Windows 95 system with Internet Explorer 3.02 or later on it should be fine, as should any Windows NT machine with Internet Explorer 4.01 or greater installed. Users who do not have either of those products installed on their computer should read the Java directions at the VisualRoute home page.) The actual VisualRoute install file can be downloaded from http://www.visualroute.com/download.html. VisualRoute is a straightforward tracert utility in most regards -- just enter the IP address or domain name you wish to trace in the input box provided, and the program will attempt to analyze all network traffic between the user's current ISP and the target ISP. What makes VisualRoute special is that it provides a global map with diagrams showing each "hop" on the route's path. VisualRoute will also attempt to explain why certain "hops" are not directing traffic properly. (Note: make sure that the "graph guesses" box is always checked to receive the maximum amount of debug information possible.)
Other Helpful Links Troubleshooting DomainsThe Situation: The solution: |