Analyze Application Response Times

The position of the PacketShaper in the corporate network — monitoring and controlling all the traffic that passes — gives it a unique opportunity to provide accurate response-time measurements at a very low cost. Because it already classifies every packet, the PacketShaper can easily calculate the time traffic spends traveling between a client and a server and the time used by the server itself. Rather than collecting response data, the PacketShaper notes response times as traffic passes.

Note: Response-time measurement data is not collected on PacketShaper ISP models or on the PacketShaper 1200 model.

   Steps:

1. Determine if you want to measure response times for:
   
   
   • Real traffic in real users' transactions
     Choose a traffic class for which you'd like to investigate response times, and continue with the next step of this recommendation. For example, if you have HTTP traffic, you could analyze response times on the web. If you have an traffic class for an ERP application such as SAP, you could choose that.
     
     
   • Automated, manufactured, standardized, synthetic transactions, created for the explicit purpose of measuring performance
     Initiate standardized, artificial traffic, creating correesponding traffic classes, just to analyze behavior. Then continue with this recommendation using the classes for your synthetic transactions.
     
     
2. Examine your Monitor Response Time window.
   
   This window lists a variety of performance-related information for each traffic class with response-time statistics.
   
   PacketWise measures response times for TCP transactions. Transactions are inherently bi-directional with both inbound and outbound traffic. Although an application usually has two traffic classes (one for each direction), PacketWise chooses one class (the one representing the client-to-server travel direction) to track and display the round-trip transaction response times.
   
   For example, you'll find response-time metrics in /Outbound/HTTP for external web-page transactions (outbound URL requests and their associated inbound web content). And that's the class that appears on this Monitor Response Time screen.
   
   
3. Find the row for your class of interest. Note the figures in the columns for average total delay, server delay and network delay.
   
   The total delay reflects all time required to service a transaction request and return the response. This time consists primarily of the time transactions spend on the network and the time the server requires to process the request. A sluggish network, an overloaded server, or a particularly large number of packets per transaction can all delay a transaction.
   
   Suppose, for example, your HTTP's total delay shows 3700 milliseconds. That means that your web transactions used over three and a half seconds, on average, to complete. That's pretty slow. Suppose the average network delay is 3450 milliseconds and the average server delay is 250 milliseconds. This tells you that the network is the main time-taker for your web transactions.
   
   
4. Find the figure for your class' round-trip time (RTT). This figure represents the time for precisely one packet to travel from client to server and back. It removes the factor of transactions' size and the impact of size on network delay. If RTT is significantly smaller than the network delay, then sizable flows are to blame for inflated network delay rather than a sluggish network.
   
   
5. View your class' response-time graphs and adjust the interval at the top to cover the time of interest.
   
   
   These graphs give you a visual representation of your traffic's delay figures over time and highlight the good periods and the bad. Are there specific times that correspond to poor performance?
   
   
6. If your server delay is slow, set Worst Servers on your traffic class to determine which servers are delivering the slowest processing times.
   
   
7. If your network delay is slow, find out what else is going on during these slow times. Display the utilization graphs for the entire link for the same interval of time as your Transaction Delay graph. Compare the two graphs. Do the spikes in overall utilization correspond to the spikes in network delay?
   
   
   
8. Reset the time period at the top of your Network Performance Summary window to cover only the interval during one of the peaks in delay time and utilization. Then examine Top Ten pie chart. Which applications were the main contributors to the link utilization during this time of slow performance? These are some of the applications that need better bandwidth management.

Slow response times can be improved. If the culprit is server delay, then you can pursue options such as load balancing and application tuning. If the culprit is network delay, then PacketWise can help. Follow these steps:

1. Figure out which traffic is undermining the performance of your critical traffic with the techniques above or those in the Identify Performance Saboteurs recommendation.
   
   
2. Put a protective control strategy in place to throttle back truly greedy traffic, pace important traffic that shouldn't dominate, protect urgent traffic, and so.
   
   
3. Define the threshold that separates good performance from bad performance for your traffic of interest.
   
   
4. Specify the percentage of transactions that should stay within your definition of "good" performance.
   
   
5. And finally, keep tabs on your application's performance by monitoring its adherence to your performance goals. You can graph the Service Level Compliance graph or even monitor response time automatically and notify yourself when compliance is poor.