In our last post, we talked about the importance of business transactions for applications in the cloud. They’re also crucial for managing highly distributed applications. But what is a business transaction?
Consider a business transaction to be a user-generated action within your system. The best practice for determining the performance of your application isn’t to measure CPU usage, but to track the flow of a transaction that your customer, the end user, has requested.
A business transaction can take different forms based on your particular industry. Here are some examples:
One way to think about the business transaction is to consider that it ties business operations and the application together, representing how user requests are being serviced.
Once you’re monitoring business transactions, you gain the ability to determine your application’s performance baseline, identify SLAs, and significantly reduce the time it takes to drill-down and troubleshoot problems. Let’s look at a few examples of how business transactions support the application owner’s ability to manage performance.
Use Case #1: You can’t manage because you can’t see
The most basic use case for business transactions is to get a true picture of your application environment. As strange as it sounds, AppDynamics hears this from our customers all the time: after they see a complete application map, they’re surprised by what the topology reveals. They’ll say, “Why is that call going to THAT database? And why is it taking so long?”
If your e-commerce service is making multiple calls to an inventory service, it could be the point of the bottleneck – but unless you understand how transactions are flowing, it may take you too long to reach that conclusion. And that’s just in regards to a single hop. When it comes to multiple hops over a distributed system, it becomes even harder to understand how the architecture of the application may be affecting performance.
Use Case #2: You don’t know where to start when firefighting
Business transactions can help you with one of the most important components of firefighting: prioritization.
If everything in your application is slow, how do you know where to look? Should you treat every node equally, and look through log files until you find a problem?
If you’re focusing on business transactions, you have a better way. You can zero in on the business transactions that appear to be problematic – such as the one performing 8 calls a minute when the standard SLA is much faster than that.
Even in a distributed environment, you don’t need to search through a needle in a haystack. You can zero in on the transactions that are the most likely culprits in regards to poor performance.
Case #3: You need to get surgical
Once you’ve determined where the performance problem is, you need to do a lot better than say “Well, it’s the Request a Quote transaction.” In order to ensure rapid collaboration with your colleagues on the development side, you need to get to the line of code that’s causing the issue.
Business transactions allow you to do this because they’ve helped you triage the situation and locate where the performance problem is actually occurring. As a result, it’s relatively simple to get to code-level quickly, turning root cause analysis into a matter of minutes rather than hours.
In this case, it’s a SpringBeans call to an external database that’s taking up too much time, and is likely the cause of the situation:
When Application owners are able to identify the line of code causing the problem, and give that code to their Development team, they contribute to rapid iterations that help ensure strong application performance.
In short: business transactions are the only way to manage applications in dynamic environments, whether physical or cloud. Don’t attempt to get by on infrastructure or JVM/CLR metrics alone!