Workshop

S: The problem might be network congestion.
O: The problem occurs at the same time on different major network segments.
A: Login congestion is likely on major segments, but not as likely on a segment with fewer users.
P: Check maps and try the applet on a “low traffic” network segment (perhaps nearer to the
Internet segment and away from segments with server login traffic on them).
You deploy your plan: You temporarily set up a workstation at point C on the map. When you try the
applet at 8:00, it works! You have now pointed the finger squarely at network congestion. The next
question is, whose problem is this? In other words, is this something that the applet vendor is responsible
for, or is this your problem for having a network that’s too busy?
Your response to this problem may vary. On one hand, it may be practical to move this person to a less
busy segment. However, this might not work, because you can see from your physical maps that the
network segments near PCs tend to have a lot of PCs on them and are smack in the middle of the servers.
In other words, physical constraints might prevent you from putting this person on a segment without
other PCs, because the only hubs near her probably are being used for other users. A hub with less traffic
might be in your data center or in another building, outside of her physical reach. (The smart aleck might
ask, “Why not ask this person to stop doing her work process at 8:00 in the morning?” Not a great
solution—the network is supposed to work, darn it!)
At this point, if you really needed to have this person’s workstation live on a busier segment, you have to
start application troubleshooting. Why is it that this person doesn’t have any other problems, say, with
local applications? As you’ll see in Hour 19, “Internet/Intranet Troubleshooting,” comparing a local
application to an Internet application isn’t a good idea; using Internet applications is like taking an
international flight versus hopping in your car to go to the store. Lots of things can happen between here
and Paris. You write down your SOAP again:
S: Applet is not working; other applications are.
O: The applet is the only Internet application in the mix.
A: Internet applications are not local applications.
P: Try a different Internet application during peak hours.
You’ve now done five SOAP lists. Long and tedious, isn’t it? Yet, as you can see, SOAP is a powerful
process for refining what you know, as well as a way to take guesses and turn them into fact and a way to
keep you moving forward.
You try a different Internet application at 8:00 the next morning, and it works like a champ. Even though
it doesn’t do exactly the same thing, at least you’re now comparing apples to apples—that is, a firewalldependent
wide-area application to another firewall-dependent wide-area application. You try yet another
Internet application, just to make sure, and it, too, works just dandy. Here’s your latest SOAP:
S: The application itself seems to be at fault.