Although network monitoring has been prevalent for decades, many systems administrators are just now recognizing the benefits of proactive network testing. Technology's rapid growth has traditionally placed administrators in a firefighting, reactive mode, so they study the network's functionality only when a device or service goes down. Through proactive network testing, you can measure how applications function under various network conditions. Thus, you can forecast and plan the network's behavior to eliminate future network problems. Regular testing lets you reduce downtime, improve network performance, speed deployments, increase user satisfaction, and make more efficient use of employee time and company resources.
Testing can also help reduce the cost of purchasing an application. Running a product through tests on your network or in a lab environment is a useful way to determine whether the product will perform up to its specifications, before you purchase the product. Testing lets you enter negotiations with the vendor knowing how well the product performs in your production environment and gives you the expertise to ask the vendor to address the product's limitations. You can use testing to precisely define hardware requirements for a product before you make purchases. You don't want to spend money for a quad-processor machine when a single-processor model will perform adequately, and you don't want to pay for a point-to-point T1 circuit when a 256 kilobits per second (Kbps) frame-relay connection provides enough throughput. Determining the application's network requirements helps you predict how the new application will affect other applications' traffic on your network.
The costs associated with downtime and application purchases are too great for you to postpone application testing on your network. (For information about common types of application testing, see the sidebar "Planning a Test." ) Use the Network Monitor tool that comes with NT Server to test an application's throughput on your network. Then, analyze the results to diagnose network bottlenecks for software you already own or to prepare your network for a new software package.
Using Network Monitor
Network Monitor is a powerful network analyzer that tracks information up to the network layer, filters packets according to their protocol or their source or destination machine, and conducts packet analysis. Network Monitor consists of an agent, which sends packets to the Network Monitor buffer, and tools, which interpret and report data the agent gathers. (For information about installing Network Monitor, see Paula Sharick, "A Newbie Meets NT's Network Monitor," June 1997, and Curt Aubley, "The Beginner's Guide to Optimizing Windows NT Server," August 1997.) Click Administrative Tools, Network Monitor on the Programs menu to open the program.
Network Monitor prompts you to select an agent if your local agent isn't running. To connect to an agent on another system, select Networks from the Capture menu in the main Network Monitor window. Select the name of a computer that is running the agent. You need administrative rights on both machines to connect to another machine's agent.
After Network Monitor connects to an active agent, the Capture window appears. Click Start Capture on the window's toolbar (it looks like a play button). Statistics will begin to accumulate. Screen 1 shows the Capture window for communications between the local machine, BOZO, and another machine, 0060978FA696. (To instruct Network Monitor to identify machines by their familiar names instead of their NIC addresses, right-click the address, select Properties, and enter the machine's NetBIOS name).
Stop the capture to analyze individual packets' statistics. Select Stop from the Capture menu or click Stop and View on the toolbar (the button's icon shows glasses over a solid square). The Frame Viewer window will appear. Double-click a particular frame to display its contents. Screen 2 shows the Frame Viewer window for communication between two computers, BOZO and KRUSTY, via the Internet Control Message Protocol (ICMP--the protocol that ping uses). When I double-click frame 7, the data portion of the frame appears; it consists of the alphabet in lowercase. This data is the payload (the data segment of the packet) that Windows NT uses when it sends ping packets.
To analyze an application's throughput, you need only the information in the top pane of the Frame Viewer window--the source and destination computers, the packet's departure or arrival time (depending on which computer you perform the capture on), and which protocol the packet uses. (For more information about using Network Monitor, see Michael P. Deignan, "Network Monitoring with SMS," July 1997.)
Setting Up an Application Test
Connect an NT server and NT client that are running Network Monitor to create a simple test network, as Figure 1 illustrates, or install Network Monitor on a client and server on your production network. On a test network, the cloud shape in Figure 1 represents a WAN link or router connection and any devices you install between your client and server to emulate your production network. On a production network, the cloud represents all the devices on the network between the computers that you're running the tests on.
The following example explains how to analyze a conversation between two computers. Many transactions involve more than two computers. Additional machines complicate the analysis, but you can break down complicated transactions into a series of conversations, each of which involves only two computers, then analyze all of the transaction's conversations.
To begin your tests, select Filter from the Display menu and instruct Network Monitor to capture packets coming to and leaving from your test client and server. Determine the types of requests the application generates--for example, an application might send separate packets to request, deposit, and change a record. Take the following three steps for every type of request the application makes: Start capturing packets in Network Monitor on both machines at approximately the same time. Use the client to request information from the server. Stop capturing packets when the conversation is complete.
In the Frame Viewer window, examine each capture on the client and server to determine how many packets traveled in each direction, how large each packet was in bytes, and when each packet left its source computer and arrived at its destination computer. For example, Screen 3, page 166, shows a capture on BOZO of the transfer of an NBT packet from BOZO to KRUSTY. The packet was 1493 bytes long, and it left BOZO at 35.024 seconds into the capture.
To save capture information for future reference, enter the information manually into a spreadsheet or export it to a text file. To export Network Monitor data to a text file, select File, Print and print the capture to a file.
Analyzing the Results
Figure 2 illustrates the traffic flow for a conversation between two machines. The client sends a request packet to the server to initiate the conversation. The request packet arrives at the server after a network delay. The server processes the request and sends a reply to the client. The reply packet arrives at the client after a network delay. The client processes the reply, and the cycle begins again. Figure 3 introduces variables and equations that can help you use Network Monitor data to quantify each step of your network's packet-transfer process.
Because your two machines' clocks must be perfectly synchronized for one-way network delay times to be accurate, you're better off measuring a request's round-trip delay. To calculate a request's round-trip delay, compare the server and client captures to determine when the request and reply packets left their source machine and arrived at their destination machine. Find the difference between the time that the client sent the request packet and the time that the client received the server's reply packet. This amount is the total time the request took for the round trip (TRT). This value includes the round-trip network delay (RT), the server's processing time (Ps), and the time each machine took to place data on the network and retrieve data from the network, which equals the size of the packet divided by the computer's LAN bandwidth (Pkt/BW).
After you calculate a conversation's total round-trip time, find the difference between the time the server received the request and the time it sent its reply. This figure is the server's processing time. Subtract the server's processing time from the total round-trip delay to come up with a temporary figure for round-trip network delay. Now, factor out the amount of time that the request packet waits for the client to place it on the network and the server to retrieve it from the network, and the amount of time the reply packet waits for the server to place it on the network and the client to retrieve it from the network. Add these four delays, then subtract the sum from your temporary figure for round-trip network delay. This is the application's correct round-trip network delay.
You can use the results of your application tests to calculate the speed at which the application is running (AppRate). To find the application's speed in bits per second (bps), add the sizes in bits of the client's request and the server's reply. Then, find the difference between the time that the client receives the server's reply and the time that the client sends its next request packet. This figure is the client's processing time (Pc). Divide the sum of the two packets' size by the sum of the total length of time that the round trip took and the client's processing time.
These calculations determine the speeds of individual packet transfers. A typical client-server conversation consists of many packet transfers, but you can use one or more packet transfers to estimate a whole conversation's throughput.
Improving Application Performance
Use the results of your calculations to speed slow applications. Look at the TRT, RT, and Ps variables. You want to keep these numbers as low as possible. TRT needs to be below 1.5 seconds; Ps shouldn't exceed 1 second for most queries; and RT needs to be below 0.5 seconds for WAN links and 0.2 seconds for LAN links.
If your server's processing time is too slow, you can increase the server's speed to improve performance. If the server's processing time and the round-trip network delay are both fine but the total round-trip time is slow, you can increase the bandwidth of your network connections to reduce the time each machine takes to place packets on the network and read data from the network. The round-trip network delay is too complicated for such a simple solution, but if you find that your RT variable is too large, you can perform network simulations to determine what is causing the excessive delay and where you need to add network resources. I will delve into network simulations and methods for reducing network delays in a future article.