Today, you rarely find applications housed in a single data center. Instead, geographically distributed companies have applications spread across multiple locations, if they even manage their own applications at all anymore. With SaaS and all the various forms of cloud computing, applications are becoming even more widely distributed, introducing new challenges in the ability, and the responsibility, to monitor application performance.
All of this dispersion is re-introducing some basic network issues that for a long time have been mostly ignored – most notably latency. In the last decade when applications were consolidated into a single data center, and accessed via a tightly controlled and monitored enterprise network, latency became at first very predictable, and subsequently not a problem at all. But the sands are once again shifting, and the move to distribute applications, both within the enterprise as well as with third-party application service providers (SaaS, cloud, or otherwise), requires that we once again pay attention to latency, and in a way that was not necessary to consider with consolidated applications.
Fortunately we’ve had a little practice, or at least a little experience, with today’s more complicated network latency. The web, and especially Web 2.0 based applications, introduced us to the concept of multi-tier, or multi-hop, applications. This “multiplicity” comes in two forms. First, the path between a web client and a web server can traverse multiple servers along the route, with each “hop” being a source of latency, sources we often have little to no control over. Second, a single, web-based transaction may require access to multiple back-end servers to fulfill a single transaction request, with these servers widely distributed with different, multi-hop routes to each server. This makes for a highly complex latency picture.
When our reliance on the web was mostly to find remote bits of information scattered around the globe this latency was of little consequence. We waited a bit longer than we expected sometimes, but the data wasn’t mission critical so it really didn’t matter very much. But now we’re distributing our client-server enterprise applications in exactly the same way, and more and more often requiring the web as our connectivity to the applications. Now, “time is money”, and just accepting latency and the increased response times that result is absolutely unacceptable. We must have the appropriate solutions in place, and at multiple locations, to adequately measure and troubleshoot the exact sources of latency. The key to answering this question and pinpointing what’s responsible for the latency creating poor application performance is in monitoring and analyzing Application Response Time (ART).
Application response time is the time it takes an application to respond to a specific user request, measured from the user’s perspective, through the combination of the network and application services infrastructure. Measuring the performance of a distributed application is essential for ensuring an acceptable user experience. In order to properly measure overall performance and calculate ART, you need to be able to distinguish the two key types of latency, the network response time (NRT) and the transaction response time (TRT). The NRT relates to overall network propagation delays while the TRT relates to processing latencies by the application itself. To learn more about how to measure application response time, watch this webcast.
A key factor in solving application performance issues is having the ability to analyze network traffic conversation by conversation, down to the packet level. Network engineers need to be able to see an overall application “in action,” including all of the network connections spawned by the application request – packet by packet – to truly understand the overall performance and the individual contributions from all of the related sources. This kind of packet-level network analysis is the best way to get the data needed to help solve ART issues. But remember, everything is now distributed so monitoring from a single location, like your WAN link, is not enough. You need a distributed network analysis solution that collects data from multiple locations, including remote client locations, and that performs both deep packet analysis when a problem does occur, as well as high-level monitoring that keeps you aware of how your applications are functioning on an ongoing basis.
With more and more companies moving business critical applications to the cloud, network administrators should be aware of how cloud computing affects the performance of distributed applications. From a network perspective, whether your servers are located in your data center or in the cloud, you still need to monitor and analyze your network traffic. However, with the cloud, you are shifting from managing your own infrastructure to managing service availability and performance. It is also important to keep ART and latency in mind before you shift your applications to the cloud. Latency typically increases when you move to the cloud because the distance to application and data servers can increase greatly, as does the number of network hops.
In tandem with accurately measuring application response time and performing deep packet analysis, a network analysis solution for distributed applications should also provide 24/7 monitoring. Ongoing monitoring can provide insight into network performance on key interfaces, and can alert you when conditions begin to decline. Before you can tell if network and transaction response times are snowballing out of control, you must have an understanding of what “normal” means for your network, and the only way to get that is through ongoing monitoring. Benchmarking your application response time and your network provides you with details of how your applications regularly perform, preparing you to address issues just as they begin to degrade.
Keeping up the performance of your applications is essential to your business. Having a proper distributed network analysis solution is key to staying ahead of network and transaction performance issues, especially with today’s distributed application architectures. In order for network engineers to manage multi-tiered, cloud-based applications without leaving their office, they need a properly equipped network analysis solution that goes beyond traditional point-and-shoot troubleshooting.
Author Profile - 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.
Recent Comments