IT Trenches

Sep 25 2009   3:15PM GMT

Performance monitoring dashboard – fping and URL ping

Troy Tate Profile: Troy Tate

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.

URLping vs fping

URLping vs fping

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.

URL pings vs ICMP pings correlation

URL pings vs ICMP pings correlation

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.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: