Achieving Rapid Time-to-Value with AppDynamics

At AppDynamics, we are firm believers in demonstrating the value of our platform as quickly as possible. Many of our customers are able to address critical performance issues within minutes of getting their application instrumented. Below is an example of how we use AppDynamics with a fictional customer, AD-Betting, to analyze and troubleshoot the company’s business environment soon after AppD is up and running.

Getting Started

After allowing AppDynamics to watch the AD-Betting environment for a few hours, we were able to see the company’s environment, how its components were interacting with one another, and user interactions. Here is AD-Betting’s architecture diagram as represented by a close-up view of our Application Flow Map:

First we examined the last hour of AD-Betting’s performance data:

Even without having detailed knowledge of the application, we knew for certain the average response time increase at 3:00 p.m. wasn’t related to a scalability issue, as the load hadn’t increased at the same time.​

To investigate the performance issue further, we reduced the time range to cover only the problematic peak. The resulting flow map showed the HTTP call between the tier (aggregator) and the external service (ad-soccer-games.com) took four seconds on average:

With a single click on the aggregator tier, it was easy to identify the impacted business transaction (/quotes):

With a single drill-down click on View Business Transaction Dashboard, we could see how “/quotes” was impacted by this issue. The scorecard for this transaction (below) uncovered a direct correlation between the spike in application response time and an increase in “Slow” and “Very Slow” transactions:

To find the root cause, we switched to Transaction Snapshots view and filtered for slow and very slow snapshots, which AppDynamics had collected automatically. We then picked one snapshot as an example and looked at the Call Graph, which showed the call for method aggregateWithoutCaching in line 217 took five seconds. The connected HTTP exit call terminated with SocketTimeoutException: Read timed out. We also verified this issue with other snapshots at the same time and—voila!—AppDynamics had uncovered the root cause of the performance issue:

To better understand the issue’s impact, we used AppDynamics’ End User Monitoring to analyze AD-Betting’s most important page requests sorted by end-user response time. We immediately spotted the slow end-user experience for FIFA 2018 – All Games, which was an extremely critical component of the company’s business, particularly with the World Cup underway. This was one issue we needed to analyze further.

Looking at the waterfall diagram of all views for this particular page, we discovered that most of the transaction time was spent on the backend, not on the network or browser side:

We then picked a single browser snapshot for closer examination. Since AppDynamics correlates frontend (browser) and backend (Java) automatically, we were able to get an associated backend snapshot as well. In this case, we diagnosed the Call graph and again found the same performance-impacting issue. As you can see, the problem was impacting one of the company’s most important pages:

We hope this simple walk-through of AppDynamics’ powerful monitoring and diagnostic capabilities helps you analyze and troubleshoot your own business-critical environments. Take the AppDynamics Guided Tour to learn more!

Spot the Difference in AppDynamics 3.4

Okay, admit it. The title Spot the Difference in AppDynamics 3.4 caught your attention, especially after we just recently announced our free End User Monitoring features, and now you’re here to find out what other insanely cool stuff we’ve been working on to enhance the experience for APM aficionados, customers and people like you! I’m proud to say that AppDynamics continues to innovate by leaps and bounds which enables our customers to be more successful in how they manage application performance and availability.

Here’s an example of us staying ahead of the curve. I was scouring Twitter feeds several weeks back and found this tweet from a Java applications guy,


Hmmmm, a proverbial question indeed.

So what exactly changes with an application release?

Flashback to 2008…I ran into a painfully similar situation back at LG. We had a team of consultants working on Java performance optimizations for eight months, executing test cases, refactoring application code, disabling trigger objects and even redesigning some of the use case workflows. Well, it turns out the build and deployment team pushed the entire application onto a completely different set of infrastructure, and when the new test results came back we almost choked when we saw 20-30% regressions in application performance. That night the performance team drank itself into oblivion, and you can imagine what happened next.

For the next two weeks everyone on the project was now heads down trying to identify what changes caused such a massive slowdown to the system. Remember, we didn’t have an APM solution like AppDynamics, and had to resort to using four different performance monitoring tools, since we didn’t have a single solution that provided us with complete end-to-end visibility. Those were tumultuous times when Ops, Dev and IT teams engaged in heated arguments about who was at fault.

All of this could have been easily avoided if we had something like AppDynamics 3.4 Agile Release Analysis to compare application releases visually. Having this type of comparative analysis capability comes in handy when you’re trying to understand why a user login transaction, for instance, is slower with your latest agile release than what it was a week ago. You could always conduct code diffs on your releases, but sometimes it’s incredibly valuable to be able to visualize performance infrastructure changes at a glance rather than having to spend hours or even days manually verifying what differences actually occurred.

Agile Release Analysis

AppDynamics release analysis rolls up application performance metrics so you can compare KPIs of not only the application, but also individual business transactions, as well as their flow and execution. The application might’ve have gotten slower, but being able to identify which piece of the overall application or specific transaction is affecting performance is much more useful to operations and IT.

Speaking of comparing Application Flow Maps, in order for this feature to be truly tenable, we needed to improve the visibility challenges customers were facing with our original flow map. We had the right idea, but it was too rigid. Monitoring several thousand tiers became blinding for some customers, leaving App Ops with a cluttered forest, and no trees. So to stay true to our company mission with offering customers with maximum visibility with minimal effort, we improved the viewing experience so you can now navigate your entire application just like you’d navigate the entire world with Google Maps. The next time you’re notified there’s an issue with a transaction that’s traversing through a particular node in a cluster, you can feel confident it’ll be easy to spot and zoom in on. The application flow maps now change color in real-time depending on the SLA and performance of application tiers and the flows that connect them. For example, here is a screenshot of the new flow map with baseline comparison enabled:

Zoom in and out of your App Flow Map

 

Introducing Role-Based Perspectives

Let’s assume the role of a database administrator for a moment. Sure, they might look at Java or .NET code once in a blue moon, but their technical domain is managing the backend of the application. So in 3.4 we decided to streamline the troubleshooting process from a role-based perspective to help our respective backend admins “get to the point” and view information pertinent to their role.

“Show me the top SQL calls for my database.” Done.

“Okay, now which business transactions do my SQL queries impact?” You can think of it as a “Where Used” look up that allows the DBA to analyze what they’re interested in from a role-based perspective and see how queries are contributing to business transaction performance. The Backend Specialists – DBA, Message Broker, ESB and Security Administers – can now say with conviction, “I optimized my backend service that was impacting the user experience of several mission critical business transactions.” That’s what I call getting bang for the buck performance optimizations!

Reporting on Application AND Business Activity.

AppDynamics 3.4 also includes a new PDF reporting engine so you can generate, save and share reports detailing application health metrics. We’ve introduced several prepackaged reports as well as the ability to create your own custom report. All of the aforementioned cool 3.4 features offer some amazing technical benefits that speak to those in DevOps, but at the end of the day, someone is going to ask how this is impacting your business’s bottom line. So in 3.4, we now allow you to build a dashboard that monitors business activity for your most revenue-critical apps. Albeit, our technology is pretty slick as it is to auto-discover and baseline your application’s performance without the need for manual instrumentation. However, there may be users or scenarios where you may want to monitor the activity and revenue of your application, rather than say its performance or throughput. No problem – you can exploit “Information Points” in AppDynamics to track any business metric or value which is part of a business transaction. Our intuitive dashboard builder lets you expose any metric with drag and drop widgets meaning you can create powerful business views in minutes.

There are a number of other powerful features and product enhancements in AppDynamics 3.4 you can start exploring today by registering here for a 30-day free trial. If you’re already an AppDynamics customer, we look forward to hearing more feedback on how we can improve the experience even further and want to say thanks again! We hope you’re as delighted as we are about our latest release.