Maximizing Application Performance: How to Extract Practical Data from Your Network

How many applications do you use that exist only on the computer in front of you? Two? One? None at all?

I occasionally use two applications that live locally on my computer, but all the rest, including every application I use for personal and professional work, are delivered over the internet.

That’s pretty much where we are these days, isn’t it?

Most of the applications we use for work and our personal lives are delivered over the internet and the local network we happen to be on that day.

That means a tremendous amount of application performance information is inherently embedded in the network itself. Today, a big part of identifying the cause of application delivery problems, such as slowness, instability, and insecurity, is looking at an application’s network activity.

Maximizing an application’s performance means extracting useful information from the network itself.

Don’t get me wrong — there’s good information we can get from looking at an application’s code, server logs, underlying compute resources, and overall architecture, but because of how we consume applications today, we must take a more network-centric approach to application performance visibility.

Even a properly designed SaaS application with sufficient compute resources and a robust architecture still relies on a separate system of network protocols, switches, routers, firewalls, DNS servers, and load balancers to reach an end-user.

All of the activity happens over the network.

Those application performance metrics are embedded in flow data, eBPF, packet captures, and the results of synthetic tests.

In the past, we’d use that type of telemetry to learn from a macro level what applications are running on our network, which IP endpoints are in those conversations, which interfaces are used on which routers, what the CPU utilization of our core is, and so on. Network-level stuff. Important, but not enough.

Now we can parse network telemetry to identify application-specific performance metrics and even make inferences about non-network resources.

Let me give you a few real examples from my personal experience.

A network-centric view of application activity can tell you that the server hosting the back end of your EMR is taking a long time to respond to the request from the front end. Because the server is responding over the network, you can see exactly when it finally does respond and that there was no delay in the network itself. We can infer that the issue is with the server itself.

A network-centric view of application activity can tell you it’s taking an abnormally long time to resolve a hostname related to your CRM platform. That one slowdown affects the entire application’s performance over the network and impacts the user’s experience. And from the network, you can determine exactly which DNS server is the culprit.

A network-centric view of application activity can tell you the number of server turns occurring to fulfill a user request to the front end of your payroll app. Digging deeper with a synthetic page load test, we can discover that one particular file is failing to load over the network and the number of server turns is exceptionally high.

With a network-centric approach to application monitoring, we can identify one tiny corrupt file hosted in the cloud that’s ruining the entire user experience.

Yes, sometimes the network itself is the cause of the performance degradation (I’ve seen my share of interface errors and power supply failures). Still, very often, it’s some other component of the application’s architecture that is not part of the network.

A network-centric approach to application monitoring gives us new and valuable insight into an application’s performance — insight you can’t get from server logs and a code review. When troubleshooting application performance, the answers are often right there — embedded in the same network the application depends on.