Five Root-Cause Reasons Your Applications Are Slow
End users are complaining. Your boss is upset. The pressure builds for you to finally fix that slow application everyone depends upon. Where to start? Here are five all-too-common reasons your application performs like molasses on a cold day — and ways to find and fix them.
Webinar: How to Troubleshoot Web Applications Using Network Data
Is poor application performance keeping you up at night? Learn how you can easily:
#1. Sluggish client
The solution: With a high-quality Application Performance Management (APM) system such as Riverbed SteelCentral™ AppResponse, you can easily identify clients with this type of internal-processing delay and differentiate application pauses from human “think time” delays.
#2. Slow server
The problem: Server teams don’t like to hear it, but the most common causes of slow application performance are the applications or servers themselves, not the network.
Modern applications are typically deployed on a multi-tiered infrastructure:
- A front-end web server talks with an application server that talks with a middleware server that queries one or more database servers
- Then, all of those servers all might talk with DNS servers to look up IP addresses or map them back to server names
When that happens, just one weak link will slow the whole application down.
The solution: To identify the culprit, you must understand the interactions between multiple components in an application. This process, called Application Dependency Mapping (ADM), uses information from preexisting monitoring solutions as part of an integrated APM approach.
Fortunately, the network provides a perfect vantage point for ADM, meaning the network team can significantly help the application and server teams. Keep in mind, however, that using packet capture tools to discover whether the network or application is to blame could take many, many hours of work.
To save time, SteelCentral AppResponse lets you quickly and easily identify the cause of slow application performance. Once the proper monitoring points and basic configurations are set up, it provides immediate ROI and is a breeze to use. What’s more, the information gathered provides Riverbed SteelCentral™ APM software with the input it needs to automatically draw dependency maps of critical applications.
#3. Diminutive databases
The problem: Applications developed on a fast LAN with a small data set seem to operate smoothly in the lab. But once rolled out into production, all bets are off. And, as the database continues to grow, so does your downtime.
The solution: In this case, a quick analysis with SteelCentral AppResponse might show that a key middleware server is making too many requests to a database server. (In fact, just one client request can result in many database requests or the transfer of a significant volume of data.) Simply making the database query more efficient typically solves the problem.
In another instance, a database server may take several seconds to return data to the middleware or application server. The application team can then use the SteelCentral AppResponse to identify the offending query.
#4. Chatty conversations
The problem: Another common cause of application slowness is chatty conversation: one application server, or perhaps the client itself, will make many small requests to execute a transaction on behalf of the person running the application.
However, with the advent of virtualization, the server team may have configured automatic migration of the server image to a lightly loaded host. This might move a server image to a location that puts it several milliseconds further away from other servers or from its disk storage system. And milliseconds can pile up fast.
The solution: To resolve this problem, you need visibility into the number of requests between systems, where the systems connect to the network, and into the delays between requests.
#5. Slow network services
The problem: Lastly, slow network services can slow application performance, which doesn’t implicate the network itself, but the services that most network-based applications depend upon.
Consider an application that makes queries to a nonexistent primary DNS server. With no response, the application must time out the first request before attempting to query the second DNS server. In that situation the application periodically slows down, but it runs fine the rest of the time.
The solution: Intermittent problems like these are very challenging to diagnose. This is where SteelCentral AppResponse comes into play, as it watches and records all transactions all the time. Just identify the time of the slow performance and look for the root cause in the data.