Application Response Measurement

May, 2008
by Phil Mason

Related Papers
Using ARM 3.0 to Measure Response Time of Intranet Java Servlets
Chris Molloy

An Implementation of ARM
Larry D. Wittorff

ARM Yourself For Continuous Availability
Jodi Perry

Monitoring and Diagnosing Applications with ARM 4.0
Mark W. Johnson

ARMing Apache
David Carter

Performance Modelingwith Application Response Measurement (ARM): Pros and Cons
Yiping Ding

See more
Join CMG

If you want to get information about the performance of your SAS programs, there are a range of methods that can be used. Perhaps the easiest is simply to use the following code, which will provide resource usage stats after each step.

Options stimer fullstimer ;

This will give you stats like this:

real time 0.01 seconds user cpu time 0.01 seconds system cpu time 0.00 seconds Memory 158k OS Memory 12400k Timestamp 12/05/2008 13:07:11

If you want to get more detailed information, SAS provides support for the ARM (Application Response Measurement) API.  To accomplish this, SAS provides ARM macros which can be called and will write performance data to a log. SAS also provides ARM macros which can be used to analyze the log that is produced. You can read all about how ARM is used within SAS here at http://support.sas.com/rnd/scalability/tools/arm/arm.html

With the ARM macros you will get the CPU times and memory, as you do with FULLSTIMER, but also get more information. Here is what you can get:

  • SAS dataset I/O processing info
  • IOM server processing info
  • SAS procedure & data step processing info
  • OLAP server session info

To use ARM properly you define transactions within your code by using the armstrt macro to indicate the start of a transaction and the armend macro to indicate the end of a transaction. You can also use arminit to signify the start of an application and armgtid to indicate a transaction class. In order to get the maximum benefit from ARM you must use these and other macro calls throughout your code very carefully. However, if you just want to get some quick & dirty ARM information from an existing SAS program then you can use the following technique.

Technique to automatically ARM code

First we define 2 macros, which will be used in place of the DATA and PROC statements. This will mean that if we have PROC PRINT ; then our macro will run, enabling us to do some extra processing before we invoke the print procedure.

%macro data / stmt parmbuff ;

  options noimplmac ;

  %armstrt;

  data &syspbuff ;

  %put WARNING----> data &syspbuff ;

  options implmac ;

%mend data ;

 

%macro proc / parmbuff stmt ;

  options noimplmac ;

  %armstrt;

  proc &syspbuff ;

  %put WARNING----> proc &syspbuff ;

  options implmac ;

%mend proc ;

 

Then we use the code to initialize the ARM system so that it is prepared for use.

options noimplmac ;             * ensure implicit macros are turned off ;

options armloc='c:\myarm.txt' ; * define location for arm file ;

options armsubsys=(arm_all) ;   * define which arm subsystems to use ;

%let _armacro=1;                * global macro variable to indicate ARM macros are outside the data step ;

%let _armexec = 1;              * enable ARM macros ;

%arminit(appname='Test App',appuser='Phil');

%armgtid(txnname='My transaction', txndet='this is my nice transaction');

options implmac ;               * use this to turn on statement overrides to automatically ARM code ;

 

Then, we simply code the example SAS program in which we want to generate the ARM log.

data test /view=test ;

  set sashelp.prdsale ;

  file='1' ;

run ;

data test2 ;

  set test ;

  file='2' ;

proc summary data=test ;

  class country ;

  output out=sum ;

run ;

proc print data=sashelp.prdsale ;

run ;

 

Lastly we stop the ARM system and analyze the ARM logs. This produces some SAS datasets and views which can be used for reporting.

options noimplmac ;

 

%armstop(status=0) ; * stop transaction ;

%armend ;            * end application ;

%armproc(log='c:\myarm.txt') ;

%armjoin;

 

Now we can look at the datasets created in the WORK library. A subset of them is listed below:

  • App ... contains an observation for each application found, along with application name, userid, transaction counts, application response time, etc.
  • TXN1, TXN2, etc. ... one transaction dataset for each application with start/stop times, wall time and CPU time.
  • TxnView ... joins all TXN datasets together and presents them in a single view
  • Updt1, Updt2, etc. ... one update dataset for each application with datetimes, elapsed time, CPU time and update data.
  • UpdtView ... joins all UPDT datasets together and presents them in a single view

I hope this gives you a taste of what you can do with SAS and ARM. Read the documentation from SAS for more information since I have only scratched the surface of this topic.