At one time or another, you've no doubt found yourself stuck sitting in your car in a massive traffic jam, wondering what in the world could have made things go so wrong. The same traffic jams occur on the Internet (in the form of long wait times for pages to download), but thankfully there are a few ways to prevent them from happening on your site. Let's look at a few common causes of Internet traffic jams, and how you can correct some of them.
To get an indication of response times and general Web traffic conditions worldwide, you can check the Internet Traffic Report. Also, many Internet service providers (ISPs) have a network status page that lists Net traffic problems, such as a broken link in the Internet backbone.
If you have a site monitoring service, such as WebPartner's SecretShopper, you can compare your site's weekly and/or monthly download performance to benchmark indices, such as the WebPartner 100 (WebPartner measures each site's performance against those of the WebPartner 100, the leading e-commerce and/or portal sites chosen by PC Magazine). Internet-wide problems usually will show in these indices and will help you determine if slow response times are occurring just on your site, or if it is an Internet-wide problem. (If download times for your site and these indices are both slow, then it is likely that the problem is Internet-wide.)
Your ISP or Host
In order to determine whether site traffic problems are occurring at the ISP or host level, you can use the "Traceroute" feature in your operating system (in DOS, Unix, Macintosh, etc.) or VisualRoute to examine the number and time length of hops to a test IP address (VisualRoute is actually just Traceroute with a nice interface). Examining the number and time length of hops will not only tell you how much delay might be occurring with URL requests to or from your site due to router hops, but also at which node(s) the delays are occurring. Windows users can access Traceroute by opening a DOS window (from the Start button, it will appear under Programs/Command Prompt).
Let's use WebPartner's site as our test site. At the C:> prompt, type the IP address of the test Web site, like so: tracert 192.168.1.20, and hit Enter to see each hop between your machine and the server on which WebPartner's Web site is located. You could also use the test site's URL and enter: tracert www.webpartner.com, which is easier. When I typed the IP address for workz (126.96.36.199) into Traceroute, for example, it showed that there were 15 hops between the WebPartner and workz sites, and it was evident which hops took the longest.
If you know that surfers are receiving error messages such as "Error 503 Service Unavailable" when they try to reach your site, a detailed explanation of such messages is available on WebPartner's site.
Your Web Server
Both ISP problems and server problems can be analyzed using another site on the same backbone as yours as a test site, to compare download times. You'll want to use a test site that is as close to yours as possible by hop count from the backbone. If this test site shows considerably better performance than your site (with consideration of the data size of the page), this indicates that the problem is either with the server your site is on or with your PC's connection to the Internet.
Again, in my example above, my URL request for workz's site took three hops just to get through WebPartner's host. Complex networks at a host, or elsewhere on the Internet, lengthens download times, which customers experience as being a problem on your site -- they're not going to perform tests to find out what's causing the traffic jam!
Here are a few ways you can determine whether another site is on the same backbone as your site. You can use VisualRoute to find out; as part of its readout, it shows the backbones (by actual name, such as "AT&T") that a traced "HTTP Get-request" travels over. (Traceroute gives you some clues about the backbones, but you need to be somewhat informed to know what you're looking at.) You could also ask your ISP what other sites it hosts. Or, you probably know some online companies that are located near you. This isn't a foolproof way to know which backbone a company's site is on, but geographical proximity does narrow the field most of the time.
Your Web Site Content
Last on the list of suspects for causing traffic problems is your Web site content. The things you'll want to consider regarding the speed of your page download times are the number, size, and nature of your image files; whether these images are on a remote or local server; and whether there are third-party components (such as banner ads) slowing down your page. Aside from optimizing the content of the page, you can also use content distribution services (such as Akamai or Inktomi) to speed your Web site response time.
Slow download time is a leading reason customers abandon purchases, or leave your site altogether. Customers do not perceive bottlenecks on the Web as being any different from slow download times on your site: to them, slow is slow, no matter the reason for it. Hopefully the above troubleshooting tips will enable you to make sure traffic snarls at any point between you and your customer don't bring your online store to a halt.
Copyright © 1995-2000 Pinnacle WebWorkz Inc. All rights reserved. Do notduplicate or redistribute in any form.