How to proceed: What to do with the results

Online section / Tutorials / QArm Tutorial / How to proceed contact | download | sitemap

It was already mentioned in the first chapter that the ARM interface is standardised but the way how data is collected and analysed is up to so-called agents and management applications. The official ARM SDK from the Open Group website can be used to verify your instrumentation,i.e. your code can be compiled and is running but you will see only some debugging output (logger interface) or nothing (null interface).

This is where MyARM comes into play. MyARM provides an ARM standard (ARM 2.0 and ARM 4.0) compatible library, some agent implementations as well as management applications. Please have a look at the MyARM website to get further documentation about the available tools.

MyARM agents, a few examples

Within MyARM context, agents uses so-called datasinks, while management applications are using datasources to retrieve measured data. This tutorial will just mention a few datasink examples and how they process measured data.

The sqlite3 datasink is a storage datasink, is very easy to use and is a good choice to use for the tutorial examples. The measurement data written by ARM4 interface functions is directly written into the SQLite database. Other storage datasinks are the mysql or oracle datasink.

Figure: The sqlite3 datasink

The tcp or file datasink should be used for applications running hundreds (or even thousands) of transactions per second. A good example for that case is the SQLite example in our tutorial (with "_fullTest" set to "true"), where about 30.000 transactions have to be handled in a very short time.

Figure: The tcp datasink

The tcp datasink is a so-called transport datasink because it just transports the data to an other process (here myarmtcpd] as depicted above. Other datasinks are the route datasink, the thread datasink.

A third type of datasink is the trigger datasink. This is a so-called processing datasink, since here no measurement data is stored at all but only monitored for predefined thresholds. The trigger datasink then executes a predefined program. Be aware that this functionality is totally different to the scenarios shown above, it shows how flexible the ARM standard can be adapted to your needs without breaking compatibility.

Many of these datasinks exist within the MyARM context. It is easy to find the right datasink according to your applications needs. See the datasink section on the MyARM website for details on the datasinks provided by MyARM.

Independent of the way the data is collected, data will be saved in a database (either sqlite3, mysql or oracle). This is a configurable parameter and independent of the agent used, e.g. the myarmtcpd agent can write to all databases provided with MyARM.

MyARM data management applications

When the data was measured a management application is needed that is able to analyse this data. Currently MyARM provides two types of managers, a command line oriented tool called myarmquery and a web based interface built upon cgi scripts using the apache web server.

This simplified version is described in this tutorial, for a description of the full interface please refer to MYARMUG.

The MyARM command line tool "myarmquery"

This section briefly describes the command line tool to submit query instances to a MyARM data source. It allows to query any MyARM data source selecting instances of applications and transactions measured by the MyARM agent. It offers various select criteria such as application and/or transaction names, directly by their IDs, start and stop time of an instance and some other attributes of these application and transaction instances. It is possible to limit the query to a maximum number of instances to be found.

Figure: myarmquery example showing transaction measured with the apache http server

However the program allows to format the output of each found application and transaction instance by specifying an printf() like format string. For further details (and other MyARM tools besides myarmquery) please refer to the MyARM users manual provided on the MyARM website

The MyARM cgi interface, simplified

The cgi interface lets the user have a look at transaction instances. In our description we use the output from tutorial t5 as example. The cgi interface is splitted into two parts.

The command form allows the user to filter the transaction instances by different parameters. Also the way how these are presented to the user can be slightly modified. The view form presents the formerly filtered transactions in a table, the histogram form and the statistics form present this data in a summarised manner.

The command form

Figure: The command form of the MyARM cgi interface

The command form can be splitted into three lines. The first line is used to filter the transactions which will be presented to the user.

The Transactions selection lets the user decide which transaction instances will be presented. This can be either "all" or a selection by application/transaction definition pair. More than one pair may be selected
The Time interval selection specifies the time frame to be used. This can be either the last hour, the last day or even the whole set of transactions from the beginning
The Status selection can differentiate between GOOD, ABORTED and FAILED transaction status (besides ALL, which means state doesn't matter)
The User selection allows filtering by the specified user. The Qt frontend from tutorial t5 shows a field "User ID" which shows this user (normally of the form "user@hostname", but this can be any string you like). You should be able to select this user here. This allows you to differentiate between the measurements you produced and measurements from other users that might have used our web interface before.
The System selection specifies the hosts that were starting a transaction and should be displayed here. Leave it to all, to be safe (you should find your local hostname in here, but you should not select it since only the transactions started on your host would be presented)

The second line influences the way how these transactions are presented (i.e. what is shown for each transaction row) to the user

The AppName selector writes the name of the application that started a transaction in front of the transaction name. This looks like application name/transaction name, e.g. MYSQL/Query.
The User selector writes the user name to each transaction. This should be the same user as specified above in the first line (in case this was not ALL).
The SystemAddress selector specifies that the hostname should be written to each transaction row. This should be the same name as specified above in the System selection field in the first line (in case this was not ALL).
The URI is a special form of context property and is filled with the name of a web page in case this was somehow involved in the transaction. The apache arm4 module writes the name of the URI that was requested by the user into this field. It should be selected when analysing the t5 measurements, since apache was involved in this example.
The Context Properties selector decides whether context properties should be shown for each transaction or not. In case of t5, this is interesting for the MySQL transactions, since each of these writes the query string to a context property.

The third line consists of different items (mostly buttons).

The ShowTransactions button starts computing the transactions to be shown and presents these transactions to the user (see "The view form shows currently selected transaction instances" ).
The Show Children selector influences the way how these are sorted in the view. For a detailed description see section "The transaction instance form" .
The Histogram button shows a histogram of the selected transactions (see section "The histogram form" )
The Statistics button shows a statistics summary of the selected transactions (see section "The statistics form" )
The Correlate button correlates all parent/child transactions.
The DeleteAll button does what its name applies, it deletes all information about your measurements (including user names, host names etc.) from the database on the web server. You should press this button when you're finished so that following tutorial users will not be confused by your measurement data.

The transaction instance form

Figure: The view form shows currently selected transaction instances

The transaction instance form is shown beyond the command form. It shows all selected transaction instances as a table, each row representing one transaction instance. The way this table looks like is influenced by the selected values in line two of the command form. "The view form shows currently selected transaction instances"

shows a few MySQL sample transactions from tutorial t5. The status column is coloured dependent on the status value, i.e. this is green in case of a GOOD, red in case of a FAILED and yellow in case of an ABORTED transaction. The response time is the time between the start() and the respective stop() call of this transaction. The start time is the absolute time when this transaction was started (be aware that this is the time of the computer where the transaction was started and the time on different computers may differ).

The histogram form

Figure: The histogram form of the MyARM cgi interface

The histogram form creates a histogram of all transactions formerly selected via command form. In our example in "cgi_interface_histogram" all transaction instances from tutorial example t5 were selected. The y-coordinate shows the number of transactions while the x-coordinate divides the duration time into equidistant bins in the range from 0 (selected via MinRT selector) to 0.4 (selected via MaxRT selector) milliseconds (selected via RT Unit selector). The Bins editable field specifies the number of bins (here 10), the Height editable field specifies the height of each bin in pixels (here 300). The View Button creates a new view of the histogram with the actual values.

The statistics form

Figure: The statistics form of the MyARM cgi interface

The statistics form gives a short statistical overview of all transactions formerly selected via command form. These are shown as summary of all, GOOD, FAILED and ABORTED transactions per row. In our example in "figure statistics" only GOOD transactions were executed thus resulting in only two rows of all and GOOD transactions. Each row consists besides the Status (as described above) and the Count values of the following columns:

Mean RT (ms) shows the mean duration time value of all selected transaction instances in milliseconds.
Min RT (ms) shows the minimum duration time of all selected transaction instances in milliseconds.
Max RT (ms) shows the maximum duration time of all selected transaction instances in milliseconds.
The Median (ms) separates the transaction instances in two half's, one half with a duration time lower than the median and one half with a duration time higher than the median (all in milliseconds).
The Variance is the average of the differences from the mean duration time of all transaction instances.
The standard Deviation is calculated as the square root of the variance.