The surfer-bone is connected to the ISP-bone. The ISP-bone is connected to the switch-bone. The switch-bone is connected to the nap-bone. And that's just part of it. The nap-bone is connected to the back-bone. The back-bone is connected to another nap-bone. The nap-bone is connected to the host-bone. And we are almost there. The host-bone is connected to the router-bone. The router-bone is connect to the server-bone. The server-bone is connected to the web-bone. And that is how we surf the 'net! Your website is your reader's destination. Getting from Point A to Point B is not as simple as it may appear. All sorts of things can go wrong along the way. This page contains information about what you can do to get an idea of where a problem might be before calling anyone for help. So whether you have a problem getting to your site or you have a script that stopped working, you may be able to find your answers with the methods explained here.

Why won't my site respond? Is it dead or just comatose? No matter what precautions we take, our sites will every now and then fall under the weather. There are many reasons for web malaise, including: Your connection to the internet. It is quite possible you have a problem with your ISP and your access is slow. Try visiting other sites and see how the response time is. The whole internet or parts of it are slow. During peak hours, many backbone providers and local servers get bogged down with e-mail requests, etc... Problems with your server. It is possible that there is in fact a problem at your end. It can be anything from a communication routing problem to an overloaded server. Maybe you are the Yahoo! Pick of the Day. Yeah, and that is Ed McMahon ringing your doorbell! Quite often, by the time you figure out the problem, it will have somehow fixed itself. Somehow your site knows a trip to the doctor might happen and all of a sudden, everything stops hurting.

Is there anything I should do before calling the Doctor? There are some diagnostics you can perform to get an idea of what the problem might be. Before calling for help, having a good idea of where the problem might be can save you some time and embarrasment. Believe me, our former hosting company hated/loved us. If you are using Windows 95/NT, start up a DOS window and try the following: *TIP! ping your site at different times of the day and night so you can get an idea of your site's baseline. Exit your browser, FTP, and e-mail program. C:\>PING mydomain.com The computer will respond with the following Pinging mydomain.com [BIGNOSEBIRD.COM] with 32 bytes of data: Reply from BIGNOSEBIRD.COM: bytes=32 time=170ms TTL=245 Reply from BIGNOSEBIRD.COM: bytes=32 time=171ms TTL=245 Reply from BIGNOSEBIRD.COM: bytes=32 time=180ms TTL=245 Reply from BIGNOSEBIRD.COM: bytes=32 time=181ms TTL=245 This example indicates a nice, healthy, responsive site. Notice that the time for the response from the server is under 200ms, or 1/5 of a second. An unhealty connection might look like this: Pinging mydomain.com [BIGNOSEBIRD.COM] with 32 bytes of data: Reply from BIGNOSEBIRD.COM: bytes=32 time=780ms TTL=245 Request timed out Reply from BIGNOSEBIRD.COM: bytes=32 time=810ms TTL=245 Request timed out If you get no response back from the command, well the problem is very serious!

What other tests can I run? Let's consider the PING command as being the oral thermometer. If the site is not reachable or the response times are very long, we must resort to that other kind of measurement tool. In this case, it is the tracert command. This little program when run from the DOS window, shows us the journey from your PC to your site. The path you take might surprise you! What is meaningful about this test, is that we can see how long the various hops from point to point take. Exit your browser, FTP, and e-mail program. C:\>tracert mydomain.com Tracing route to mydomain.com [BIGNOSEBIRD.COM] over a maximum of 30 hops: 1 160 ms 130 ms 140 ms netsvr1.nwk.vastnet.net [207.252.73.11] 2 140 ms 140 ms 130 ms en2-dialup.border1.nwk.vastnet.net [207.252.73.1] 3 140 ms 140 ms 140 ms atm1-0-1-li-nap.nwk.vastnet.net [207.252.72.1] 4 160 ms 220 ms 221 ms ser2-0-0-14.nyc.ny.cerf.net [134.24.130.57] 5 160 ms 151 ms 150 ms atm3-0-155M.phl.pa.cerf.net [134.24.46.9] 6 141 ms 150 ms 150 ms atm6-0-155M.nynap.ny.cerf.net [134.24.46.169] 7 150 ms 150 ms 150 ms sprintnap-7010-F0-0.cwix.net [192.157.69.84] 8 150 ms 160 ms 140 ms nyd-7513-1-h1-0.cwix.net [207.124.107.37] 9 160 ms 150 ms 161 ms dcb-7513-3-a4-0-1.cwi.net [207.124.105.161] 10 180 ms 171 ms 150 ms cwi-xxx.cwi.net [222.222.222.222] 11 181 ms 180 ms 180 ms www.mydomain.com [BIGNOSEBIRD.COM] Trace complete. The example above looks pretty healthy, but it still is amazing how many systems every character must pass through to get to and from our server. Tracing route to problemserver.net [123.123.123.123] over a maximum of 30 hops: 1 150 ms 130 ms 141 ms netsvr1.nwk.vastnet.net [207.252.73.11] 2 140 ms 141 ms 130 ms en2-dialup.border1.nwk.vastnet.net [207.252.73.1] 3 150 ms 141 ms 140 ms atm1-0-1-li-nap.nwk.vastnet.net [207.252.72.1] 4 171 ms 140 ms 150 ms ser2-0-0-14.nyc.ny.cerf.net [134.24.130.57] 5 160 ms 140 ms 180 ms atm3-0-155M.phl.pa.cerf.net [134.24.46.9] 6 160 ms * 151 ms atm6-0-155M.nynap.ny.cerf.net [134.24.46.169] 7 220 ms 231 ms 240 ms atm9-0-3.svnode.sd.cerf.net [134.24.29.45] 8 231 ms 230 ms 230 ms fe0-0-0.fins.sd.cerf.net [134.24.38.226] 9 220 ms 220 ms 241 ms pos6-0-0-155M.flwr.la.cerf.net [134.24.29.74] 10 221 ms 230 ms 220 ms fe0-0-0.mums.la.cerf.net [134.24.41.226] 11 240 ms 270 ms 231 ms atm3-0-155M.sfnode.sf.cerf.net [134.24.32.18] 12 250 ms 231 ms 220 ms atm3-0-155M.paix.sf.cerf.net [134.24.29.22] 13 241 ms 240 ms 251 ms atm8-0-155M.maew2.sf.cerf.net [134.24.29.37] 14 250 ms 251 ms 240 ms mae-west.iconnet.net [198.32.136.25] 15 350 ms 321 ms 320 ms ATM1-0-7.balt01.xxxxxxx.NET [111.111.111.111] 16 341 ms 370 ms 341 ms baltimore.iprs.telco.net [222.222.222.222] 17 381 ms * 371 ms 333.33.3.33 18 * 511 ms 431 ms 444.444.44.444 Trace complete. In the example above, we have changed the names and IP addresses to protect the innocent, but it is real. Reading down all 18 hops, we can see that things look pretty good until we hit our first minor snag at #6, but things are still in the 200 range. Once we finally get back to the east coast (baltimore), we notice a 350ms average time around the hosting companies connection to the backbone. The final coup de grace is getting into the hosting company and then finally to the server the site is located on. This situation would merit a call to the hosting company. Do not call yet! Wait a little while. The problem might be temporary or actually at the backbone provider. Wait an hour or so to see if the problem clears up. There is another interesting problem here that we might want to ask the local ISP about. To get from Long Island, NY to Baltimore, Maryland my route to the server is about 6,000 miles. If I were to get in my car and drive to this server, it would only be about 250 miles! However, if the long times are located between you and your service provider, then don't bug the hosting company. If the delay is someplace in the middle, then only an entity that has no name and answers only to a greater power can help. In otherwords, it's a bottleneck on the Internet itself and you are stuck. A much more serious problem would look like this: 15 350 ms 321 ms 320 ms ATM1-0-7.balt01.xxxxxxx.NET [111.111.111.111] 16 341 ms 370 ms 341 ms baltimore.iprs.telco.net [222.222.222.222] 17 381 ms * 371 ms 333.33.3.33 18 * * * 444.444.44.444 19 * * * 444.444.44.444 20 * * * 444.444.44.444 Desination reported unreachable This means your site is down and off-line for some reason. Again, there are many causes of this problem and we suggest waiting a little while before calling. When we experience problems, we usually send a cute e-mail to the support department. We usually never call on the phone because the last thing I want to do is pull the technician away from a problem he or she most likely already knows about.

Why would a script suddenly stop working? There are several reasons why a reliable and trusted script would suddenly cease functioning, including: Your site has been moved to another server where the directory names, or the path to your site has changed. One day you are on /home/u/myweb and the next day you are in /h10/u1/myweb. The script is still being called properly, but if it has any hard coded paths in it, then the script will fail. The script was consuming too many system resources and the system administrator disabled it. If you look at the file's permissions and they look like -rw-r--r-- then this may be the problem. If you are positive that you did not do this, write to your system administrator and ask if there was a problem. New server software. On occasion, the companies that make the software that runs our sites will issue updates. It is possible that a function you need is no longer supported. If this happens, you will not be alone and your host should be able to supply you with some information on what to do. If you know the name of your server, such as APACHE, and the version number, you can go to their site and research the issue on your own. Changes in server configuration. Related to the above, hosts can tune their server software to include or exclude certain features. This is especially true with security problems. A great example of this has to do with many hosts not allowing the Server Side Include EXEC. The way around this problem is to use the VIRTUAL include. Again, when changes like this happen, your administrator should notify you in advance so you can take care of it before it becomes a problem. Self inflicted wounds. This is probably the main cause of such problems. We are guilty of it as much as anyone else. It's late at night, in a rush, not enough coffee, and we make that little tweak to a script and then not test it. The next day, the script is not working and we do not remember why. Always test your scripts after any change!

What can I do to fix a broken script? The most important thing you can do when faced with a script failure problem is take about ten deep breaths before dealing with it. Then, follow these simple steps to trace the cause of the problem. Check your E-mail. Go read your mail. Maybe there is a note from your system administrator notifying you that something has been changed on the system that might affect your site. If this is the case, then the letter probably holds the answer. If the letter does not make sense to you, the reply to the letter and ask for clarification. Check the script's modification date. Look at the directory listing for the script. If the date seems more recent than the last time you remember working on it, then either you or somebody else modified it. If you have a back-up copy of the script, compare the two and look for differences. This also applies to any related configuration files. Check the script's permissions. If you notice that the execute permission on the file has been removed, then you need to figure out if you or the system administrator did it. Often when the sysadmin does this, they also change the ownership of the script so you can't change the permissions back! As I mentioned in the last section, if this is the case, write your sysadmin for advice. Check your website's physical path. Whether using FTP or telnet, issue the pwd command to find out the full path to the directory where your script resides. If it looks no longer agrees with what paths are in your script(s), edit your scripts with the new path. If you were not notified, write your sysadmin a polite letter thanking them for not notifying you of a change that affected the operation of your site. Of course, if you find an e-mail from three days ago notifying you of an upcoming change.... Check file sizes. If your script creates a log file or other type of output file, check to see how big it is. Many sites have what is called a ulimit. Your sysadmin can advise you on this if you do not have telnet access. If you can log into your site via telnet then issue the ulimit command at the prompt. The result should be either unlimited or a number. The number is how many blocks large a file can be. You will need to then find out whether a block is 512 or 1024 bytes on your server and multiply the ulimit result by the block size to figure out the maximum file size. Fun? If you have checked everything out and all seems okay at your end, the write your sysadmin. There is a chance that some minor system change was made that they did not think would affect anything. The odds are pretty good that the checklist above will resolve most problems. You might consider placing a copy of BIRDSEYE.CGI on your server. This free script allows you to run diagnostics right from your server using browser.