Introduction
A business transaction represents a type of user request to a web application. For instance, the following types of requests are considered business transactions for an online retail banking application:
- Logging in
- Balance checking
- Funds transfer
- Bill payments
- Logging out
User experience with a web application not only relies on the successful completion of these user requests/transactions, but also on their rapid execution. This is why, even if a single transaction slows down, stalls, or fails, user dissatisfaction with the web application as a whole grows. This in turn may cause user complaints to increase, support costs to sky rocket, and revenues to dip.
To avoid such disastrous results, web application administrators should monitor every business transaction closely and promptly identify the slow/stalled/failed transactions. Most importantly, administrators will have to determine where and why these transactions under-performed – i.e., identify the root-cause of poor transaction performance - so that the problem can be quickly resolved before users begin doubting the stability of the web application.
Root-cause isolation is often the most challenging! This is because, most web applications these days overlay multi-tier environments characterized by multiple application servers, database servers, remote services, etc. Every business transaction to such web applications travels through multiple nodes, using remote calls to external services, to fulfill its purpose. For example, an online transaction to shop for goods may access a ShopCart web page on a web server. Every time an item is added to a shopping cart, the web server may make an HTTP/S call to a web application server to invoke the business logic. The business logic may then make a database call to run a query for retrieving the total count of goods that that user has shopped for so far. A slowdown in even one node or a delay in processing even a single remote service call can impact the performance of the transaction. To accurately isolate where the actual bottleneck lies, administrators should employ an APM solution that can trace the entire path of every business transaction, measure the total round-trip time of each transaction, identify the synchronous and asynchronous calls made by the transaction at various nodes, and compute the time spent by the transaction at each node, for each call. This can be achieved using the eG Java Business Transaction Monitor (BTM).
