It’s not me, it’s actually you, I mean the app that is….
Do you remember breaking up with someone and trying to ease the situation by saying, “It’s not you, it’s me” and you darn well knew it actually was them?
The network teams in your organization take a more straightforward approach, “It’s not me—the network that is—but rather, it’s you and your app!”
Here’s how all this gets started. We have two or three devices running with apps served through clouds, data centers, and the internet—smart phones, tablets, laptops, and desktops.
There’s even computer head sets now!
A lot of our app use is mission-critical for our day jobs and at other times a lot of it can be recreational or consumer related. Either way, these apps have to be running smoothly all the time.
From a user perspective, when an app is slow, what do we do? We usually switch to another device, click away, or go to the competitor’s app.
As an example, just the other day one of my music apps took forever to load and it kept timing out on the caching phase. I deleted the app and re-installed it as a first step. After that, it was still was not working well. Instead of addressing the issue with the provider, I unsubscribed from my paid membership and just switched to another provider and now the service is free for me. I won as a consumer but the provider with the slow app lost my business.
This type of behavior goes on all over the world every second of the day for millions, even billions of users for many different apps and network scenarios.
Once the network team identifies that pages are slow on an app, what do they do? It depends. What is their relationship with the app teams? Do they have the ability to share the same data they are looking at with the app teams? Can that app team investigate objectively to determine why they are being blamed for some user’s slow pages? The heartache gets shared and resolved in some environments while in others it can escalate into further blame games and it’s not me, it’s you scenarios.
Network to application team data
Let’s take a quick look at an example of some slow pages for an app using Riverbed SteelCentral AppRepsonse Web Transaction Analysis below. Wow, who would want to wait 27 seconds for a page to load, especially when other pages are loading in about 2 seconds?
Now, it’s time to break the news to the app teams. We can now see that it is a web tier of this app that is causing the issue. Talk about complexity: this call is to Akamai for some external integration of the app, which is causing the slow pages. We need to figure out why this web tier call is jamming up the app and then we can fix it. Both teams have visibility and can help each other solve this issue.
In this case the network team was gracefully able to communicate with the app team and find out what to do to address this application problem. Saying “It’s not me, it’s you, the app” is not such a bad thing after all, especially if you have complete visibility of your network and application environments.
We invite all network teams to get a little more acquainted with the app teams and provide the kind of actionable data that helps both teams. Getting started with web transaction analysis in AppResponse and then diving deeper with SteelCentral AppInternals for the complete end-to-end view will definitely help and without heartaches.
To get started with web application troubleshooting, check out this quick video on looking at Web Transaction analysis pages:
- Effective application performance monitoring (APM)
- Guess what happens when you use APM to zoom in—and then zoom back out again?
- 3 Guidelines for Troubleshooting Application Performance