Autonomic request flow manager advanced custom properties

Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Autonomic request flow manager advanced custom properties

You can use these properties to configure the autonomic request flow manager (ARFM).
Unless otherwise specified, create these custom properties on the cell using the following steps:

In the administrative console, click System administration > Cell > Custom properties > New .
Enter the name of the custom property.
Use this topic as guidance for entering the value of the custom property.
Click Apply and save your changes.
In some cases, you set the value on the node:

Click System administration > Nodes > node_name > Custom properties > New.
Enter the name of the custom property.
Use this topic as guidance for entering the value of the custom property.
Click Apply and save your changes.

Work profiler properties

Table 1. Work profiler properties

Property name Value Default

profilerPeriod A number of milliseconds, specified for each cell that specifies the length of the work profiler cycle. 60000 (1 minute)
profilerHalfLife A number of minutes, specified for each cell. The work profiler discounts observations by an exponential function of time. The half life is the amount of time over which the discount changes by a factor of 2. 600000 (10 minutes)

Work profiler output decay half life and smoothing weight function parameters

The work profiler works in two passes: first it fits the observations to a simple model to extract preliminary work factors, then it smoothes the work factors by taking a weighted average. Each weight is WebSphere XD of two factors, one of which diminishes the preliminary work factor importance with age and the other that varies with the goodness of the first pass fit. The age factor is an exponential decay; the half-life is the amount of time over which that factor drops by a factor of 2. This parameter is given in the cell with the profilerAlphaSmoothingHalfLife custom property, with a value that is the decimal notation for an integer, a number of milliseconds. The default is 10 minutes. To adjust the goodness level, two parameters are used, a threshold and a factor. The threshold is defined with the goodnessWeightThresholdcell custom property. The factor is given in the cell with the goodnessWeightFactor custom property.
Table 2. Work profiler output decay half life and smoothing weight function parameters

Property name Value Default

profilerAlphaSmoothingHalfLife a decimal notation for an integer in a number of milliseconds 600000 (10 minutes)
goodnessWeightThreshold a non-negative floating point number 20
goodnessWeightFactor a non-negative floating point number 20

Work factor overrides

You can override the values that are computed by the work profiler. The work profiler computes a work factor for each transaction class and deployed Java™ 2 Platform, Enterprise Edition (J2EE) module pair (TCM). The work factor is a floating point number that represents the number of megacycles of the reference instruction set. Work factors are used in the automated estimation of speed factors. If you explicitly defined speed factors by defining speed factor overrides, work factors are not needed.
You can override work factors by adding the custom property to the deployment target. If you defined an override in a previous release using the transactionclass.xml file, the custom property overrides that value. For nodes that are not running WebSphere^® Application Server, you can specify Magic N for the cell, specify the work factor for each related TCM pair, or put the autonomic request flow manager manual mode and specify the various control knob settings. Here is the grammar for work factor override specifications:
spec ::= case ( "," case )*
case ::= pattern "=" value
pattern ::= service-class ":" txn-class ":" application ":" module
service-class ::= step
txn-class ::= step
application ::= step
module ::= step
step ::= name | "*"
value ::= number | "none"
Speed factor overrides

Use speed factor overrides to override speed factor values that are computed by the work profiler. You can also supply speed factors to support performance management on more than one tier. The work profiler computes a speed factor for every transaction class module (TCM), that is, for every transaction class and web module pair. The override is mandatory for every non-target processing tier that might be a bottleneck.
You can specify the speedFactorOverrideSpec custom property on the deployment targets, a cluster or a singleton server. The custom property identifies an override for every TCM in the deployment target. If a specification is given, it must be complete. You can use wild cards to enable short specifications and to cover many transaction class modules. Use the following grammar for defining speed factor override specification values:
spec ::= case ( "," case )*
case ::= pattern "=" value
pattern ::= service-class ":" txn-class ":" application ":" module [ ":" tier ]
service-class ::= step
txn-class ::= step
application ::= step
module ::= step
step ::= name | "*"
tier ::= dtName [ "+" relTierName ]
relTierName ::= name
dtName ::= name ( "/" name )*
value ::= number | "none"
You can omit the tier name when it is the first processing tier of the deployment target that has this property attached. In this grammar the relTierName value is equal to a relative tier name that is unique only within a deployment target. For example, the relTierName might be cell/node/server or a cell/cluster in a WebSphere Virtual Enterprise configuration. You can omit the relative tier name when it is equal to 1. For any given TCM, the specification is processed from left to right, meaning that the first match wins. A value of none means that there is no override. Following are some examples:
Example Spec Description
*:*:*:* = none
Specifies that every transaction class module (TCM) in the deployment target has no override. The deployment target has only one tier, and the value is calculated in the normal way for each case.
*:*:*:* = 42
The deployment target has one tier. Every TCM in the deployment target has a speed factor override for the tier, equal to 42 MHz.
Platinum:*:*:* = 42, *:*:*:* = none
The deployment target has one tier. There is an override of 42 MHz for transaction class modules that have a Platinum service class, and no overrides for transaction class modules that are assigned to any other service class in the deployment target.
*:tc_A:*:*=42, *:tc_B:AccountManagement:MicroWebApp.war=17, *:tc_B:*:*=none
There is an override of 42 MHz for TCMs that have the tc_A transaction class. For any TCMs that have the tc_B transaction class, a deployed J2EEapplication named AccountManagement, and a J2EEmodule named MicroWebApp.war, there is an override of 17 MHz. There is no override for any other TCMs that have the tc_B transaction class. This example does not consider transaction classes other than the tc_A or tc_B transaction classes and if it encounters another transaction class, an error message is displayed.
*:*:*:* = none, *:*:*:*:../DbCel/CICS = 0.7
There is no override for the first tier. For the tier that is named CICS+1, a speed factor override of 0.7 exists. The CICS+1 tier is the first tier in the CICS deployment target, in the DbCel cell, regardless of the target TCM. The transaction class does not change from tier to tier, but the module might change.
External placement

An external cluster is used for foreign and generic servers that are not referenced by generic server clusters and are not monitored by the remote agent. Database servers are an example. An external cluster cannot be a target and cannot contain target servers. An external cluster server can run on any kind of machine. You must specify the placement of the external cluster servers, and the speeds of their unmonitored nodes by using a custom property on the ODR cell. Use the following grammar to specify the value of the external.placement custom property:
spec ::= nodespec ( ";" nodespec )*
nodespec ::= nodeName ":" [ nodeSpeed ] ":" plmtlist
plmtlist ::= dtName ( "," dtName)*
nodeName ::= name ( "/" name )*
nodeSpeed ::= number
The grammar and interpretation for a dtName is the same as in the speed factor override spec, except that in this situation, the relevant cell contains the node with a specified nodespec that contains the dtName. The grammar and interpretation for node names follows the same pattern. Following are some examples :

Spec value Description
CicsNode: 8.6 : CICS In addition to the WebSphere Application Server nodes and targets, there is one node that is not running WebSphere Application Server, named "CicsNode" in the same cell where this property appears. The computational power of that node is 8.6. There is one deployment target not associated with WebSphere Application Server on that node; named "CICS". One server process exists for that DT on that node.
../SysX/DBA:4.7:DB1,DB2; ../SysX/DBB:2.7:DB2 There are two nodes that are not running WebSphere Application Server, named DBA and DBB in the cell named SysX, with power of 4.7 and 2.7 respectively. Two deployment targets exist, named DB1 and DB2, in cell SysX. DB1 is placed only on node DBA, and DB2 is placed on nodes.

Use per-process CPU readings

Set the useProcessCPU custom property to true to enable the ARFM controller and application placement controller to consider background work when computing the required resources and enable per-process CPU utilization statistics. When this property is set to false, the work profiler cannot estimate work factors as well because it uses CPU utilization readings for the whole node.
Table 3. useProcessCPU custom property for V6.0.2 and later

Name Property Setting Default Valid Values

useProcessCPU Set this custom property on the cell. true true or false

MustGather documents

Use the WebSphere Virtual Enterprise mustGather documents to troubleshoot the autonomic request flow manager and application placement. The Support team provides and maintains the mustGather documents for each version of WebSphere Virtual Enterprise.

Related tasks

Configure the autonomic request flow manager
Autonomic request flow manager advanced custom properties

Property name	Value	Default
profilerPeriod	A number of milliseconds, specified for each cell that specifies the length of the work profiler cycle.	60000 (1 minute)
profilerHalfLife	A number of minutes, specified for each cell. The work profiler discounts observations by an exponential function of time. The half life is the amount of time over which the discount changes by a factor of 2.	600000 (10 minutes)

Property name	Value	Default
profilerAlphaSmoothingHalfLife	a decimal notation for an integer in a number of milliseconds	600000 (10 minutes)
goodnessWeightThreshold	a non-negative floating point number	20
goodnessWeightFactor	a non-negative floating point number	20

Example Spec	Description
::: = none	Specifies that every transaction class module (TCM) in the deployment target has no override. The deployment target has only one tier, and the value is calculated in the normal way for each case.
::: = 42	The deployment target has one tier. Every TCM in the deployment target has a speed factor override for the tier, equal to 42 MHz.
Platinum:::* = 42, ::: = none	The deployment target has one tier. There is an override of 42 MHz for transaction class modules that have a Platinum service class, and no overrides for transaction class modules that are assigned to any other service class in the deployment target.
:tc_A::=42, :tc_B:AccountManagement:MicroWebApp.war=17, :tc_B::*=none	There is an override of 42 MHz for TCMs that have the tc_A transaction class. For any TCMs that have the tc_B transaction class, a deployed J2EEapplication named AccountManagement, and a J2EEmodule named MicroWebApp.war, there is an override of 17 MHz. There is no override for any other TCMs that have the tc_B transaction class. This example does not consider transaction classes other than the tc_A or tc_B transaction classes and if it encounters another transaction class, an error message is displayed.
::: = none, ::::../DbCel/CICS = 0.7	There is no override for the first tier. For the tier that is named CICS+1, a speed factor override of 0.7 exists. The CICS+1 tier is the first tier in the CICS deployment target, in the DbCel cell, regardless of the target TCM. The transaction class does not change from tier to tier, but the module might change.