Previous | Table of Contents | Next |
Lets consider the example of a driver who stops every few minutes to go to the bathroom. This isnt exactly an efficient way to drive, but some folks do it. Similarly, some applications dont take advantage of certain protocol efficiencies. What protocol efficiencies might these be?
Lets take a look at a concrete example. Novells packet burst mode for IPX/SPX is a way for an application at one end to avoid a ping pong effect with the end station. On totally unreliable networks, its sometimes necessary to get an acknowledgment for each packet transmitted. On a reasonably reliable network, this creates unnecessary traffic. Take a look at Figure 23.1. The workstation on the right gets all the packets it needs in six transmissions; the workstation on the left needs many more to get the same data, because the application on the workstation is insisting on an acknowledgment for each packet. In large quantities, this is extremely inefficient; Novells burst mode is a way of avoiding this. However, older Novell networks using older clients dont take advantage of this feature.
Figure 23.1 Unnecessary network traffic.
A way of seriously upgrading the speed of an older Novell networkwithout a new investment in hardwareis to get the newest Client32 for your DOS or Windows workstations. Make sure that PBURST.NLM is loaded on your 3.x server (no action is necessary on a 4.x server). Youll be amazed at how much faster your network seems to run.
TCP/IP also has a burst mode called sliding windows. Why? Because, when conditions are good, the TCP window (the amount of data that may be sent without an acknowledgment) is large, but when conditions get bad, that amount slides down to compensate. When conditions are good, it slides back up.
When testing two similar applications network efficiency, you can simply do the same operation twice, measure how much data was transmitted, and come up with the throughput per second for each. I did this once with two thin-client applications and found that one client was almost four times as efficient as the other. Wow!
Application efficiency typically doesnt change unless the design of the application causes certain events to make the app handle things differently at certain thresholds (more than x indexes? More than x users?), which can affect efficiency. Unfortunately, theres no formula on how to deal with this; youll have to rely on instinct and then test your theory.
Every server can run out of resources. Once you identify which server a slow application is running on, youll want to check the following items:
Sure, every CPU can run out of gas. But most of the time, youll see less than 100 percent CPU utilization. Even when a lot of CPU cycles are available, you still can be slow. Why? It all boils down to this: Hard drives are slow as dirt, physical memory is the speed of light. Hard drives dont even begin to approach how fast memory is. Consider these analogies:
Is it that bad? Pretty close. Even when the CPU is not busy, if your program has to be paged back in to physical memory from virtual (hard drive) memory, it takes a long time, and your performance is going to suffer. How much swapping is acceptable? For an answer to that, see the Baselining section later in this chapter.
Finally, your application may be disk intensive, regardless of whether theres enough physical memory to go around. Database programs, no matter how well indexed, will suffer performance problems if theyre on nonoptimized disks. This typically isnt a new problemyoull see this from the first installation of an application. However, if index or database files grow to a certain point, taking up more disk space (and thus taking longer to load), performance may start to degrade. You can see whether your applications are disk bound by checking your waiting for I/O CPU statistic. If its a large percentage of the total CPU utilization, you probably have problems.
The only way to know for sure whether youre running out of anythingbandwidth, server resources, and so onis to measure. Everything else is guesswork. What do you measure first? It depends on your theory. Remember, youll be applying good black box troubleshooting measures when someone tells you that the network is slow. Youll identify all of the pieces that constitute the whole connection and then rule out one item at a time as the cause of the slowness. If you rule out the local segment for the moment (other people are working fine on this segment) and the route (other people who use that route for different applications are also working fine), you might suspect the server. If the server is working fine for two other applications, but you dont know whats happening on the network segment where the user is complaining, its time to take measurements on the segment in question.
How do you measure? It depends. For long-term monitoring, distributed network analyzers or management probes are probably best; for short-term problem determination, you can rely on your trusty standalone network analyzer. Intermittent problems are probably better suited to probes, and standalone analyzers for ongoing problems.
Previous | Table of Contents | Next |