Application Performance Problems? It's Not Always the Network!
A primer on how to win the application versus network argument
August 15, 2014

Don Thomas Jacob

Share this

“It must be the network!” Network administrators hear this phrase all too often when an application is slow, data transfer is not fast enough or VoIP calls drop. Now, of course, the network is the underlying infrastructure all of these services run on, so if something does not work as expected it’s understandable that users more often than not place the blame on the network.

And sometimes that blame is rightfully placed on the network. It may indeed be that there isn’t enough bandwidth provisioned for the WAN, non-business traffic is hogging bandwidth, there are issues with high latency or there is incorrect or no QoS priority. Route flaps, the health of network devices or configuration mistakes can all also lead to application performance problems and are related to the network. Despite these potential problem areas, it is certainly not always the network that is to blame. The database, hardware and operating system are also common culprits. And believe it or not, a major cause of poor application performance can be the application itself.

Application performance issues stemming from the application can be caused by a number of different factors related to the design of the application and otherwise. For example, there could be too many elements or too much content in the application; it could be too chatty, making multiple connections for each user request; or it could be slow and long-running queries. Not to mention memory leak, thread lock or a bad database schema that is slowing down data retrieval. As a network administrator, though, try telling this to the application developer or systems administrator and more often than not you’ll find yourself engaged in an epic battle.

Sure, there are half as many reasons why the source of the issue could be the network, but that argument won’t fly. You’re going to have to prove it. Here a few of the common accusations developers and SysAdmins make and how you can be prepared to refute them:

“Hey, the network is just too slow”

Response: You should power up your network monitoring tool and check the health and status of your network devices. SNMP tools can provide a lot of useful information. For example, when monitoring your routers and switches with SNMP, you can see if there were route flaps, packet loss, an increase in RTT and latency, and if the device CPU or memory utilization is high.

“Maybe your WAN link can’t handle my app”

Response: Cisco IPSLA can send synthetic packets and report on the capability or the readiness of the network link to handle IP traffic with TCP and UDP protocols or report specifically about VoIP performance, RTT, etc. If the synthetic packets generated by Cisco IPSLA that match the application protocol can be handled, they should also be able to handle the actual application traffic.

“There’s just not enough bandwidth”

Response: There’s a tool for that too! NetFlow data from routing and switching devices can report on bandwidth usage telling you how much of your WAN link is being utilized, which applications are using it, what end-points are involved and even report on the ToS priority of each IP conversation.

“It’s got to be something to do with your QoS priorities”

Response: Using a monitoring tool that supports Cisco CBQoS reporting, you can validate the performance of your QoS policies — pre and post policy statistics, too much buffer and how much traffic is being dropped for each QoS policy and class.

If your QoS policies are working as expected, it’s time to tell your foe, “Nope, try again!”

“Well, it might not be any of those things, but it’s still definitely the network”

Response: When all else fails, the answer is deep packet inspection (DPI). The visibility that DPI provides is virtually unlimited throughput information, out of order segment details, handshake details, re-transmissions and almost any other information you will need to prove once and for all that it’s not the network, and also find out the actual cause for poor application performance so you can really rub it in.

In conclusion, with the right technology and tools, network administrators can prove that the network is not at fault, but equally important they can be proactive and ensure small, routine network issues don’t become major headaches to begin with.

Don Thomas Jacob is a Head Geek at SolarWinds.

Share this

The Latest

November 19, 2019

Unexpected and unintentional drops in network quality, so-called network brownouts, cause serious financial damage and frustrate employees. A recent survey sponsored by Netrounds reveals that more than 60% of network brownouts are first discovered by IT’s internal and external customers, or never even reported, instead of being proactively detected by IT organizations ...

November 18, 2019

Digital transformation reaches into every aspect of our work and personal lives, to the point that there is an automatic expectation of 24/7, anywhere availability regarding any organization with an online presence. This environment is ripe for artificial intelligence, so it's no surprise that IT Operations has been an early adopter of AI ...

November 14, 2019

A brief introduction to Applications Performance Monitoring (APM), breaking it down to a few key points, followed by a few important lessons which I have learned over the years ...

November 13, 2019

Research conducted by ServiceNow shows that Gen Zs, now entering the workforce, recognize the promise of technology to improve work experiences, are eager to learn from other generations, and believe they can help older generations be more open‑minded ...

November 12, 2019

We're in the middle of a technology and connectivity revolution, giving us access to infinite digital tools and technologies. Is this multitude of technology solutions empowering us to do our best work, or getting in our way? ...

November 07, 2019

Microservices have become the go-to architectural standard in modern distributed systems. While there are plenty of tools and techniques to architect, manage, and automate the deployment of such distributed systems, issues during troubleshooting still happen at the individual service level, thereby prolonging the time taken to resolve an outage ...

November 06, 2019

A recent APMdigest blog by Jean Tunis provided an excellent background on Application Performance Monitoring (APM) and what it does. A further topic that I wanted to touch on though is the need for good quality data. If you are to get the most out of your APM solution possible, you will need to feed it with the best quality data ...

November 05, 2019

Humans and manual processes can no longer keep pace with network innovation, evolution, complexity, and change. That's why we're hearing more about self-driving networks, self-healing networks, intent-based networking, and other concepts. These approaches collectively belong to a growing focus area called AIOps, which aims to apply automation, AI and ML to support modern network operations ...

November 04, 2019

IT outages happen to companies across the globe, regardless of location, annual revenue or size. Even the most mammoth companies are at risk of downtime. Increasingly over the past few years, high-profile IT outages — defined as when the services or systems a business provides suddenly become unavailable — have ended up splashed across national news headlines ...

October 31, 2019

APM tools are ideal for an application owner or a line of business owner to track the performance of their key applications. But these tools have broader applicability to different stakeholders in an organization. In this blog, we will review the teams and functional departments that can make use of an APM tool and how they could put it to work ...