We discussed earlier in Observer-106 how to measure network latency. We measured the TCP connection setup process to get the network round trip response time (NRTT.) We discussed earlier that the client connects to the network which connects to the Server and the client and the server use the Application across the network.
Simply determine the round trip time through our network by timing the TCP 3 way handshake. This is our starting point and reference point to everything else this client / server / application process is going to do. After the TCP 3 way handshake the application will make some kind of request (READ or WRITE) and then the server will provide some type of reply. Let’s time this again, you see in this trace the Network Round Trip time is 77 milliseconds for TCP port 1221.
I’ll show you the easy button by looking at the Expert Window notice TCP port 1221 shows NRTT as 77.467 milliseconds. Close enough; what’s a few microseconds among friends!
Notice two sessions get set up, this tells us that the application is using HTTP version 1.1 or better and not the old version 1.0 which only used a single connection (that’s bad, bad, bad.)
Our next step in profiling the application would be to determine how many Round Trips are made to the server to retrieve data, this is also known as Application turns or Application threads. One way to find out how many threads there are is to build a pattern filter looking for HTTP GET’s or POST’s.
The Observer returned 62 frames. This says that the application is making 62 requests to the server and expects 62 responses. They should match! If not, (what’s up with that??)
To find the responses, we filter for 200 OK messages.
Apply this filter to the original trace and again you should get 62, they should match the number of requests. If they don’t that means that pages could have been moved or any number of other things, but other response codes will tell us what happened with the application. We’ll discuss those later.
It is even easier if we let expert do most of the work for us. Go back to the tab that has all of your frames. In the Expert tab, TCP Events, Choose Server Client Totals, then select the conversation by clicking the TCP pair; this will highlight this conversation, now right mouse click and choose Add Server to Application Transaction Analysis.
Make the selection to Track by URL and then click on the Configure button!
This allows us to dissect the application several different ways. We want to go 10 levels deep and uncheck the Track folders only box, but notice you can track specific URL’s or content type.
Now follow through with OK and click finish. Click on the Application Transaction Analysis Tab at the bottom right. At the top of your screen choose the Application Statistics tab and notice there are 62 - GET Requests and 62 - 200 OK Responses. This quickly shows us that the application made 62 Round trips to the server. Now for some magic math, if we take 62 (requests) * 77 (ms NRTT) = 4774 which is milliseconds or 4.7 seconds. This shows that this application transaction made up of 62 requests will take approximately 4.7 seconds to complete.
Let’s look at the last packet and notice the relative time column equals 4.5 seconds. That is close enough for you and me!
LAB 7 – Round Trips
Go back and open your capture from LAB 5 which was the client PC connecting to your web server. Make sure you timed all of the processes.
DHCP completion, Default Gateway ARP Request / Reply, DNS Request / Reply, TCP 3 Way Handshake to Web server; now time the first couple of Application Requests and Replies.
Figure out how many Application Round trips were made. Take the number of Round trips times your NRTT and see how well it performed.
Does the number of Requests equal the number of Responses?