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.
End of Article
Prev. page
1
[2]
next page -->
