Posted by: Troy Tate
application management, application performance, icmp, network design, network diagnosis, network management, network performance, performance analysis, ping, url ping, web services, webserver
In part one of this series, I discussed ping and pathping. These tools are good for some interactive realtime testing. However, what do you do when you want to run these types of tools over an extended period and then do statistical analysis? In cases like this I use the fping tool. I recently completed an analysis task requiring comparison of network ping times against web server response times. The tool I used for measuring webserver response (time to first byte) is called URL ping. Users were reporting slow webserver (Sharepoint) performance. Everyone was saying it is a network issue. Since there are so many “moving” parts between the users and the webserver farm, I wanted to prove to them that the network was not the issue but that something inherent in the way the webserver responds to the requests is the real issue.
The URL ping tool is described in the Microsoft IT Showcase: sharepoint Performance Optimization Technical White Paper. It is a C# script that will need to be compiled using the proper include files and configuration for your environment. I configured the script to log in CSV format the date, time and time to first byte from the webserver in question. Using the console output redirect pipe, I logged the information to a text log file. I configured a Windows scheduled task to run the URLping command over the time period of interest. The URLping command ran every 30 seconds logging the results to the specified text file.
During the same period, ever 30 seconds, I ran the fping utility from Kwakkelflap.com. The fping utility is much more flexible than the ping tool that is part of the Windows operating system. Some of the features that make fping so useful includes:
- Time between pings can be adjusted as needed from 1ms to 5s.
- Beep on every successful or unsuccessful reply allowing you to test your network status in the background.
- Ping multiple hosts with one simple command.
- Read a hostlist from a file
- Output redirection to a file for parsing.
- Ping with random data, or data you provide
The results from these two utilities were logged into two separate CSV files. Since the tests were running every 30 seconds, I could take the fping results and the urlping results and combine them into one spreadsheet for analysis. I wanted the units for the urlping and fping response times to be the same. I had to divide the fping results, which were in milliseconds (ms), by 1000 to convert the results to seconds to match the units of the urlping results. I then graphed the results. This information is shown below. The blue data points are the urlping results. The pink data points are the ping times.
During this sample period of 54 hours, the maximum urlping response time was about 30 seconds. The maximum fping response time was 0.4857 seconds (or 485.7 ms). The average urlping response time was 2.75 seconds and the average fping response time was 0.06 seconds (or 60 ms). As you can see, the network ping response times are much lower than the webserver response times.
We found it very interesting that there was an elevation in webserver response times from about 15:45 on 9/23/09 until just after 01:30 on 9/24/09. Note that the ICMP ping times were not elevated in a similar manner during this period. Further investigation on this issue would be required.
I ran a correlation statistical analysis to see if the fping (icmp) response times and url ping times were related. The graph below has the ICMP ping time as the X-axis and the url ping time as the Y-axis. As you can see, there is very little correlation (0.251) between the two measurements.
Based on this information, I was able to convince the team that the webserver response is not related to the network response.
These tools are simple to use and should be in your toolkit as a network administrator. How often are you told that the network is having a problem yet you know that there is something else happening? Stay tuned… more to come!
So for now – share with the other ITKE readers ways that you look at network/application performance. What tools do you use to instrument and diagnose network issues?
Thanks for reading and let’s continue to be good network citizens.