Configuring the autonomic request flow manager

When setting the aggregation period, ensure the value is high enough to allow for the collection of a sufficient number of performance samples. Samples are collected by the gateways for each request. A few hundred samples are necessary to produce a good statistical measure.

Using an example - requests associated with a service class run in 250 milliseconds, and on average 10 requests run concurrently. The concurrency value is calculated automatically, based on the cluster size and the resources in the environment. The concurrency value can be seen on the visualization panels, under the Runtime Operations category in the console. As a result, the service class handles about 40 requests per second. Therefore, setting the aggregation period value to 15 seconds results in the collection of 600 samples for each aggregation period. The metrics provided by a 600 sample survey are useful and reliable.

Setting an aggregation period value too low results in unreliable performance metrics. Performance metrics derived from fewer samples are more noisy and less reliable, then a higher sample size. Because the ARFM controller is activated when new statistics are produced, setting an aggregation period value that is too long results in less frequent recomputation of the control settings. Therefore, Intelligent Management becomes less responsive to sudden changes in traffic intensities and patterns.

A low smoothing window setting makes the controller more sensitive and react more quickly. However, a low parameter also creates a sensitive reaction to noise, or anomalies, in the data.

The product of the smoothing window and the aggregation period should be roughly the same as the actual control cycle length, which is sometimes slightly greater than the configured control cycle minimum length.

This parameter is used to bound the length of each ARFM queue to a maximum number of requests that can be held in queue. ARFM divides all incoming traffic into flows, and has a separate queue for each flow. Flow particulars include requests that have a particular service class, are served on a particular deployment target, or go through a particular ODR.

When a request arrives and its queue is full, the request is rejected.

The ARFM provides overload protection, in addition to its prioritization capabilities. An ARFM will queue requests in its gateways to avoid overloading the application servers.

For this release, load is determined in terms of processor utilization on the first tier of application servers. The maximum CPU utilization parameter tells ARFM how heavily to load the servers. During severe peak conditions this utilization limit might be briefly exceeded.

Higher values give better resource utilization; lower values give more robust operation. Real load is noisy and variable. The performance management techniques in Intelligent Management react to changes in the load, but with some time delay. During that reaction time, the system might operate outside its configured region; this includes having higher processor utilization than configured. Operation with one application server at 100 percent processor utilization for multiple minutes has been observed to break some internal communication mechanisms, to the detriment of many features.

The performance management in this release of Intelligent Management does not work well if the first tier of application server machines are loaded with other work besides WebSphere requests that arrive through HTTP through the ODRs.

This setting affects application placement. If the total predicted demand suceeds the Maximum CPU utilization limit, the placement controller uniformly reduces the demand of all the dynamic clusters before calculating best placement.

Set the arfmManageCpu custom property to false to disable processor overload protection and request prioritization. The arfmManageCpu is a cell custom property that you need to create.

The purpose of admission control for processor overload protection is to deliberately not accept dialogs based on judgments concerning how much can be accepted without overloading the compute power in the nodes being managed and compromising the response time of the accepted messages.

The Admission control for CPU overload protection value applies only to HTTP and Session Initiation Protocol (SIP); it does not apply to IIOP and JMS.

Enable it when queuing for processor overload protection is not enough; when it is important to make deliberate refusals of some offered load.

The admission control for processor overload protection is working if, in a heavily loaded system, the processor utilization is about the same as the setting for processor overload protection.

Specifies the maximum percentage of the heap size to be used for each application server.

Maximum percentage of the WebSphere Application Server heap size to use. Set the value to less than 100.

Specifies the behavior for HTTP, SIP and SOAP requests that are associated with a performance goal when an overload condition is detected.

Choose among the options to determine when to reject messages to prevent the CPU from being overloaded. You can reject no messages, or specify a rejection threshold value that determines when to reject messages. The default is to reject no messages.

Discretionary work is assumed to have a response time threshold of 60 seconds.