Concepts

Introduction

Purpose

In a modern context, applications aren't limited to a single program running on a single machine. They may involve multiple programs running on a number of machines. In fact, with load balancing technologies, it may not be possible to tell in advance which machines an application will use. The ARM (Application Response Measurement) standard provides a mechanism for determining what's going on within an application, and determine potential problem areas or problem transactions wherever they occur.

Applications

So if an application isn't limited to a single program or machine, then what is it? Well if we look at a typical multi-tiered application, there could be a web-server that accepts requests, a servlet container that does a first stage of processing and provides the final response, a business application server that provides the core logic for an application, and a database server that provides a persistent data store. Any of these areas could be a potential bottleneck, and issues with any of these servers or applications could affect the overall performance of the system.

From an ARM point of view, an application is anything you want it to be. Of course it's most useful to think of it on a function or user focused basis rather than a program or server basis. For example, a system to process accounts payable may be an application.

Since this is the highest level grouping defined as part of ARM, so some thinking may be required before deciding where to define an application. Using the previous example, is an accounts payable system an application, or is it part of a general accounting application? Sometimes this will be answered by the nature of the programs involved, but as often as not it's answered by area of responsibility. For example, if there's a specific set of coders responsible for financials as a whole, that may define the application. Similarly, if different groups are responsible for different parts of the financial processing, it may make sense to make each of them an application. The standard itself makes no differentiation, so it's often a matter of policy and architecture.

Transactions

Transactions are the next layer below applications. All transactions belong to an application and all applications have transactions. Transactions may also be composed of multiple transactions. Like applications, transactions are flexible in their definition.

In general, a transaction is a single unit of processing. From a user point of view, this may be from the point where they hit a submit button on a web page until they get a response. This is a good transaction definition, but it may not provide a good view into how the transaction is performing. For example, once they hit submit, the application may need to verify permission to perform the operation, parse the fields of the form, and make multiple database queries and updates. Since one of our objectives is to obtain performance information on all aspects of our system, it makes sense to declare each of these operations as a transaction. The ARM standard allows us to satisy all of these needs.

The transaction seen by the user is a parent transaction. Each of the individual processing elements is a child of the parent, and may have children of their own. Measurements can be taken of each of the pieces so that we can get a better view of what's happening for the parent transaction.

Correlation

Since a parent transaction may have multiple children, and each of those children can be executed anywhere throughout the multi-tier system, we need a way to relate the children and the parents. This is done through the use of correlators. As a transaction instance is created, it's assigned a unique token called a correlator. When a child transaction is created, this token is passed in as an argument and so on down the line. Knowing the parent correlators of all children, it's possible to trace a transaction through all stages of processing.

How Measurements Are Made

There are two ways an application can be measured: by the agent and by the application.

Agent Measurements

This is the most common way to measure transaction performance and is definitely the preferred method. While details will be provided in the language specific tutorial sections, the simple version is that an api call is made at the start of transaction processing, and another is made when processing is complete. The ARM agent is then able to figure out how much time has elapsed.

Application Measurements

In some cases it may not be possible for the agent to measure response times. For example, if a transaction includes a component that is not instrumented or resides off of the current system, the application has the option of measuring the response time and reporting that to the agent. While this is possible, it's usually possible to design your program to use agent measurements so this is often unnecessary.

Metrics

Getting response time information for a transaction may not give you the complete picture. For example, an FTP transfer of an 8 GB file is going to take much more time than transferring an 8 KB file. Similarly, there may be a specific PHP page that takes longer than all others. Long response times aren't always indicative of a problem. Similarly, a page returning a HTTP 404 error may have a much lower response time than if the page were executed correctly. Metrics give us an insight into what goes into a specific application instance.

Metrics are user defined, and like many parts of the ARM measurement, selecting good metrics is a skill. In general you want to include information that helps clarify the performance of the application. In the ftp example just given, this would include the size of the file transaction. For a web server, it may include the URL, or the type of object served such as a PHP page or a graphic file. The language specific tutorials give good examples of how to use metrics.