Store discount coupons and multi-tier applications - two things you probably didn’t expect to read about today, yet together, they impact millions of people.
Think about the following scenario: Your grocery store offers car fuel discounts for every $100 you spend on groceries. Every week my family, probably like yours, buys our weekly groceries and then heads over to the gas pump to fill our tank for the week with the gas discount we just earned.
But what is the IT process that ensures this activity happens without error? As expected, it's quite simple at a high level:
- The grocery expenditure is recorded on a grocery store membership account and the amount of the fuel discount eligible with this purchase is also recorded on the account.
- The updated account information is immediately synced with the entire system to ensure accuracy at the gas pumps.
- When the user enters membership account information at the pump, the correct discount is applied to the gas purchase and the customer is happy – thank you multi-tier application infrastructure!
Chances are the servers and storage that house all the applications and information resides in a data center located thousands of miles away from the grocery store.
The applications most likely have a multi-tier architecture with a front-end that is connected to the point-of sale systems and the applications that manage the accounts, and a back-end database that houses all the account information, purchase history and discount eligibility.
But, what happens if the information transfer is somehow delayed in the grocery store and gas purchase process is impacted? What if customers have to wait at the pump for their discounts to come through or worse, the discounts are bypassed because the system has timed out?
The loss of customer confidence would have a massive impact on the business.
But this isn’t just theoretical - it's a real-world example I've encountered. And, it was solved by leveraging an APM solution that gave the business complete visibility into their multi-tier application infrastructure.
To ensure problems are identified before they impact a system – or can be quickly resolved if they are impacting users – troubleshooting multi-tier applications is key for a variety of businesses, not just grocery chains. Problems are often complex and challenging to determine root cause.
So, where do you begin? Traditional troubleshooting methods that rely on gathering data from single points on the network don't provide the visibility needed to troubleshoot the problem effectively.
Furthermore, ownership of the infrastructure that supports the applications is another challenge. Traditionally, each team owns different products and tools they use to look at a section of the problem (single point), but they don’t often get complete insight into the entire problem or network. Figure 2 shows how these sections are typically segmented.
Figure 2
In order to find root cause, an IT professional needs to see an action from the user and the corresponding actions from the application and database servers, in other words, an end-to-end action (Figure 3). This is the most effective way to troubleshoot multi-tier applications and save valuable time. APM offers this holistic view.
Figure 3
While most APM solutions on the market today use similar methods to collect data, the difference lies in how the information is presented to make it easy to identify a multi-tier application performance problem. The following (Figure 4) is an example of the type of data presentation that clearly shows the relationship between the user action to the resulting application and database actions (this is common payroll-type application).
Figure 4
The user requested payroll information from a web application and is experiencing slow performance. Since this is a multi-tier application, there are other applications behind the web application. The user can drill further into the encompassed transactions to view the backend transactions that occur during the request/response time frame. These transactions are red since they exceeded the normal expected response time. Since the first transaction had the worst response time, the user can drill in further to see the backend transactions.
Figure 5
At the top part of this second screen (Figure 5) is the original Payroll transaction the user had selected. The rest of the transactions on the screen show the next tier application that happens to be MySQL and Oracle transactions. These transactions occurred during the request/response timeframe for the Payroll transaction. As the database response times are normal, hence the problem domain lies in the web application. This sort of end-to-end visibility allows the user to quickly isolate problems in multi-tier applications.
As I wrap up the post, I’d like to circle back to the grocery store chain story I was talking about earlier. Customers were denied the gas discounts when at the pump. Further investigation via an APM solution showed that a 20-millisecond delay in the database caused a 9 second delay in the overall system. That delay was just enough to cause a time out for the POS system on the discount validation request causing customers to be ineligible for the gas discount.
Without having the ability to see the correlated actions of each tier of the application, it would have been very difficult to identify this problem. This is a great real-world example of how APM helped solve a real customer problem that was resulting from a lack of visibility into the multi-tier application infrastructure.
A key takeaway to consider when selecting a solution to monitor multi-tier applications is to be sure that the data is presented in a format that shows the user action with corresponding application and database actions. Collecting application data is easy -the magic is in how the information is presented to support the workflow of troubleshooting a multi-tier application.
Belinda Yung-Rubke is Director of Field Marketing for Visual Networks Systems.
Related Links:
