Users are experiencing slow Application Response Time (ART) and the blame goes first to the network, so the network engineer - you - must once again climb into the ring for the classic match between network and application performance. The best outcome is a knock out in the first round, allowing you to address the frustrated user as quickly as possible. So, what can you do to help guarantee that the fight will be quick?
The Weigh In: Create Your Baselines
In order to determine if users are experiencing unusual latencies, you of course have to know what is usual on your network. Part of your preparation for the fight is to be sure to baseline your network, with a focus on both network and application latencies, before entering the ring. Be sure to assess latencies across a wide range of users (especially those in different physical locations) and your full range of applications. When possible, collect network traffic at multiple locations, with one being as close to the users as possible and the other as close to the application and data servers as possible. The value of a baseline is in performing trend analysis, so run baselines at regular intervals to possibly even see issues before users report them. It’s impossible to predict the winner if you don’t know your network’s and applications’ normal behavior, as well as how new applications may affect your network.
Scoring the Fight: What to Look for
The point isn’t to win or lose the fight (though it always feels great to bring explicit proof to an application designer that there’s a problem in the application and not in your network), it’s to address the users’ problem as quickly as possible. After all, your network is your corporate lifeline. Presumably you’ve already seen from your baselines that performance is below expectations, so you need to break the problem down into possible issues, the first being if it is the network or application that is causing the issue.
Using a detailed network analysis solution that monitors packet traffic will allow you to investigate the clues. A solution that includes visual analysis of packet flows per conversation and detailed analysis and reporting of network faults is most helpful here, and it must include the ability to report on packet response times. Clues to look for on the network side include slow acknowledgements, TCP SLOW segment recovery, slow and frequent retransmissions, and low throughput. Application problems manifest themselves in HTTP slow response times (for web-based applications), database slow response times and inefficient clients. For example, if in the visual analyzer you see that client requests are being acknowledged very quickly (very responsive TCP ACKs), but the corresponding data packets with actionable payload data that fulfill the client request are slow in coming, the problem is most often with the application. However, to conclusively prove whether the slowdown is the result of an application or a network issue, you’ll need deep packet analysis capabilities.
Declaring the Champion: Deep-Packet Analysis
As the network engineer, you must prove unequivocally if it is the application or the network causing the increased latency. The only way that you can specifically and accurately do this is through packet-level monitoring and analysis. With packet-based monitoring, you can inspect the conversation between a client and a poorly performing application as described above to determine what’s causing the delay – network or application. And often times when the responsiveness of application payload data is poor, the payloads themselves contain detailed clues as to why.
The referee has declared the problem solved! If it is a network problem, you’ll get the diagnostic information you need to remedy the issue quickly. And if it’s an application problem, and therefore out of your control, you’ll have solid proof to send along to your application engineer, cloud service provider or whomever is in control of the application side of things.
Author Bio: Jay Botelho is the Director of Product Management at WildPackets, Inc., a leading network analysis solutions provider for networks of all sizes and topologies. Jay holds an MSEE, and is an industry veteran with over 25 years of experience in product management, product marketing, program management and complex analysis. From the first mobile computers developed by GRiD Systems to modern day network infrastructure systems, Jay has been instrumental in setting corporate direction, specifying requirements for industry-leading hardware and software products, and growing product sales through targeted product marketing.