Application Testing with Network Monitor

Use this NT Server tool to evaluate application speed across your network

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, improvenetwork 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, beforeyou purchase the product. Testing lets you enter negotiations with the vendorknowing how well the product performs in your production environment and givesyou the expertise to ask the vendor to address the product's limitations. Youcan use testing to precisely define hardware requirements for a product beforeyou make purchases. You don't want to spend money for a quad-processor machinewhen a single-processor model will perform adequately, and you don't want to payfor a point-to-point T1 circuit when a 256 kilobits per second (Kbps)frame-relay connection provides enough throughput. Determining the application'snetwork requirements helps you predict how the new application will affect otherapplications' traffic on your network.

The costs associated with downtime and application purchases are too greatfor you to postpone application testing on your network. (For information aboutcommon types of application testing, see the sidebar "Planning a Test.") Use the Network Monitor tool that comes with NT Server to test anapplication's throughput on your network. Then, analyze the results to diagnosenetwork bottlenecks for software you already own or to prepare your network fora new software package.

Using Network Monitor
Network Monitor is a powerful network analyzer that tracks information up tothe network layer, filters packets according to their protocol or their sourceor destination machine, and conducts packet analysis. Network Monitor consistsof an agent, which sends packets to the Network Monitor buffer, and tools, whichinterpret and report data the agent gathers. (For information about installingNetwork Monitor, see Paula Sharick, "A Newbie Meets NT's Network Monitor,"June 1997, and Curt Aubley, "The Beginner's Guide to Optimizing Windows NTServer," August 1997.) Click Administrative Tools, Network Monitor on thePrograms menu to open the program.

Network Monitor prompts you to select an agent if your local agent isn'trunning. To connect to an agent on another system, select Networks from theCapture menu in the main Network Monitor window. Select the name of a computerthat is running the agent. You need administrative rights on both machines toconnect to another machine's agent.

After Network Monitor connects to an active agent, the Capture windowappears. Click Start Capture on the window's toolbar (it looks like a playbutton). Statistics will begin to accumulate. Screen 1 shows the Capture windowfor communications between the local machine, BOZO, and another machine,0060978FA696. (To instruct Network Monitor to identify machines by theirfamiliar names instead of their NIC addresses, right-click the address, selectProperties, and enter the machine's NetBIOS name).

Stop the capture to analyze individual packets' statistics. Select Stopfrom the Capture menu or click Stop and View on the toolbar (the button's iconshows glasses over a solid square). The Frame Viewer window will appear.Double-click a particular frame to display its contents. Screen 2 shows theFrame 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 consistsof the alphabet in lowercase. This data is the payload (the data segment of thepacket) that Windows NT uses when it sends ping packets.

To analyze an application's throughput, you need only the information inthe top pane of the Frame Viewer window--the source and destination computers,the packet's departure or arrival time (depending on which computer you performthe capture on), and which protocol the packet uses. (For more information aboutusing Network Monitor, see Michael P. Deignan, "Network Monitoring withSMS," July 1997.)

Setting Up an Application Test
Connect an NT server and NT client that are running Network Monitor tocreate a simple test network, as Figure 1 illustrates, or install NetworkMonitor 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 anydevices you install between your client and server to emulate your productionnetwork. On a production network, the cloud represents all the devices on thenetwork between the computers that you're running the tests on.

The following example explains how to analyze a conversation between twocomputers. Many transactions involve more than two computers. Additionalmachines complicate the analysis, but you can break down complicatedtransactions 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 instructNetwork Monitor to capture packets coming to and leaving from your test clientand server. Determine the types of requests the application generates--forexample, an application might send separate packets to request, deposit, andchange a record. Take the following three steps for every type of request theapplication makes: Start capturing packets in Network Monitor on both machinesat approximately the same time. Use the client to request information from theserver. Stop capturing packets when the conversation is complete.

In the Frame Viewer window, examine each capture on the client and serverto determine how many packets traveled in each direction, how large each packetwas in bytes, and when each packet left its source computer and arrived at itsdestination computer. For example, Screen 3, page 166, shows a capture on BOZOof the transfer of an NBT packet from BOZO to KRUSTY. The packet was 1493 byteslong, and it left BOZO at 35.024 seconds into the capture.

To save capture information for future reference, enter the informationmanually into a spreadsheet or export it to a text file. To export NetworkMonitor 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 twomachines. The client sends a request packet to the server to initiate theconversation. 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 forone-way network delay times to be accurate, you're better off measuring arequest'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 (P_s), 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 thedifference between the time the server received the request and the time it sentits reply. This figure is the server's processing time. Subtract the server'sprocessing time from the total round-trip delay to come up with a temporaryfigure for round-trip network delay. Now, factor out the amount of time that therequest packet waits for the client to place it on the network and the server toretrieve it from the network, and the amount of time the reply packet waits forthe server to place it on the network and the client to retrieve it from thenetwork. Add these four delays, then subtract the sum from your temporary figurefor round-trip network delay. This is the application's correct round-tripnetwork delay.

You can use the results of your application tests to calculate the speed atwhich the application is running (AppRate). To find the application's speed inbits per second (bps), add the sizes in bits of the client's request and theserver's reply. Then, find the difference between the time that the clientreceives the server's reply and the time that the client sends its next requestpacket. This figure is the client's processing time (P_c). Divide thesum of the two packets' size by the sum of the total length of time that theround trip took and the client's processing time.

These calculations determine the speeds of individual packet transfers. Atypical client-server conversation consists of many packet transfers, but youcan use one or more packet transfers to estimate a whole conversation'sthroughput.

Improving Application Performance
Use the results of your calculations to speed slow applications. Look at the TRT, RT, and P_s variables. You want to keep these numbers as low as possible. TRT needs to be below 1.5 seconds; P_s 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 forreducing network delays in a future article.