The concept of an application transaction (also called a business transaction or an end-user transaction) is at the heart of Application Performance Monitoring (APM). A previous three-part article, The APM Primer (part one, part two, and part three), described the basics of APM. The article now before you delves a little deeper into APM’s core concept, the application transaction.
What is an Application Transaction?
An application transaction is a sequence of user and system activities that are perceived by the user to be a logical unit of work. Technically, this definition includes activities outside the computer (e.g., going to the store to buy printer paper), but for convenience, we consider only those parts of the transaction that are within the computer system and the man/machine interface.
A few practical examples aid understanding. The following are application transactions:
- logging in or out
- searching for a product
- adding a product to a shopping cart
- paying for an order
- adding a record to a database
- updating a profile
Why is This Concept So Important?
As techies, we tend to think a lot about the performance, availability, and security of system resources. Of course, that’s a good thing. After all, it is our job. Our systems would fall apart if we weren’t doing it.
However, it is equally important to consider performance as seen by the end-user. After all, these are the people who will evaluate their experiences and vote with their dollars. If the end-users aren’t happy, they will complain or go elsewhere. If enough end-users go elsewhere, the company folds and we end up sending out résumés again.
System owners and senior management are more attuned to the end-user experience than they are to technical matters. Some believe that management without measurement is impossible, so they want to measure what they know. This puts measurement of the end-user experience at the forefront in their minds.
How Do You Measure Performance of an End-User Experience?
Stop right there! We’re not ready to measure anything yet. First, we have to identify the end-user transactions. The system owner or a business delegate is better equipped for this step than more technically-oriented people. In fact, it’s probably better if the business delegate knows relatively little about the internal workings of the system. The best person for this job is someone who works closely with the end-users.
Start with the transactions that generate the most calls to the help desk. The help desk agents routinely ask, “What were you doing when the problem occurred?” This information should be tracked because it helps identify and prioritize the problem transactions.
Consider, too, the functionality that was most recently transferred to production. Newer code is more likely than older code to cause problems because older code has been production tested longer.
Questionnaires to end-users may be useful, but only if the political clime is supportive of this approach. Management is more likely to approve questionnaires to internal end-users than to external end-users. Keep the questionnaire as open-ended as possible. You don’t want to guide the end-users’ thinking; you want them to guide yours.
Now that you’re finished your fact-finding mission, define the application transactions in terms of end-user actions (e.g., clicks, words typed) and system responses (e.g., a page is displayed)
Now Can I Measure Performance?
Absolutely! It’s now time to create monitors for the transactions. How do we do that?
The Paid Monitor system is probably the easiest to use. You download a plugin for your browser, click the record button, and complete one transaction. Cloud-based monitoring then takes over and recreates the transaction repeatedly at suitable intervals. As it does, it measures the time required for each step, both from a user’s view and from a system view. If anything takes longer than the time you specify, the system notifies the contact person by phone, SMS, or e-mail. You can view the results (both coarsely-grained and finely-grained) via the Paid Monitor web interface at any time, and even view the web pages that cause problems.
Paid Monitor calls this Transaction Monitoring. There are no scripts to write and no code to change. Non-technical people can define the application transactions and create the monitors. This sets your technical gurus free for the more challenging task – responding to notifications, analyzing the data, and resolving technical issues.
The Paid Monitor tutorial video (bottom of page) demonstrates how to create monitors for logging in and out, adding items to a shopping cart, searching for flights at a travel centre, and using a credit card to pay for an order. The fact that four application transaction monitors can be demonstrated in only 6½ minutes of a video says a lot about ease of use.
It’s On Its Way
APM is on its way. Because it is still in its infancy, its definitions and framework will undergo some changes over the next few years. Right now, though, it is time for sysadmins to familiarize themselves with the basic concepts so they can intelligently advise senior management and system owners.
Demonstrating a mockup of application performance monitoring to your management chain can be helpful, both to you and to them. You can do this quickly and easily with Paid Monitor’ free 15-day trial or at monitor.us. Either way, there is no cost to you or your company. It’s a great opportunity to be seen as proactive.
Since application transactions are at the heart of APM, understanding this concept is the best way to get started. I hope the above has been useful for that purpose.
References
The Application Performance Monitoring Primerby Warren Gaebel.
