Ensuring that your network and applications are performing optimally is essential for your business. Application performance relates to the time it takes an application to respond to a specific user request, measured from the user’s perspective, through either the network and/or the web services infrastructure. Application response time is often broken down into two key components – the network response time, which addresses just the network latency, or the time it takes data to get from one end of the network to the other, and the transaction response time, which addresses the processing time required by all application processes.
In order to make sure your applications performing properly, you need to first determine what optimal performance is, and have tools in place that can perform 24/7 monitoring on your applications.
Application performance depends heavily on network performance, so if your network is not performing correctly, then your users will experience problems with their applications. If an application is not performing properly users typically blame the network as the culprit for the issue. If a problem arises and users become frustrated with the performance of an application, which is really the only perspective that an end-user has, the first step is figuring out what is causing the problem: the network or the application.
Network or Application
To prove unequivocally if it is the application (transaction response time) or the network causing the problem you need an analysis solution based on deep-packet inspection. With packet-based analysis, you can inspect and even visualize the conversation between a client and a poorly performing application, packet by packet, to determine what’s causing the delay – network or application. A user request followed by a quick network acknowledgement (ACK) but a delayed data response is indicative of an application issue, while delayed or even missing ACKs indicate a network issue. Often times when the responsiveness of application data is poor, the application data payloads themselves contain detailed clues as to why – for example – database error codes embedded in the data packet payload.
Network issues are shown through slow acknowledgements, TCP slow segment recovery, slow and frequent retransmissions, and low throughput. Application problems manifest themselves in slow HTTP response times (for web-based applications), slow database response times, and inefficient client errors.
Catching the problem before it becomes an issue
Before you can tell if network and transaction latency are snowballing, you must have an understanding of what normal means for your network. Benchmarking your application response time provides you with details of how your applications regularly perform. When you are establishing an application benchmark, pay close attention to both network and transaction latencies and assess whether or not they appear across a wide range of users (especially in different locations) and/or a wide range of applications.
Finding the Right Technology to do this
Again, a key factor in solving application performance issues is having the ability to analyze down to the packet level. However, having only a packet-level view is not enough. Be sure to look at solutions that provide both high level monitoring capabilities that can keep you aware of how your applications are functioning from a business perspective, as well as perform deep packet analysis when a problem does occur.
Again, keeping up the performance of your applications is essential to your business, and understanding how to monitor both network and transaction performance, as well as their interaction, will help you keep your users happy and your network healthy.