WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Configuring the autonomic request flow manager

You can fine tune the autonomic request flow manager (ARFM) by changing the default settings in the administrative console.

Before you begin

To change the settings on the autonomic request flow manager, you must have operator, configurator, or administrator administrative privileges. Operators can only view the information on the configuration tab, but can change the settings on the runtime tab. Configurators can change settings on the configuration tab, but cannot change settings on the runtime tab. Administrators have all privileges.

When security is enabled, some fields are not editable without proper security authorization.

About this task

The autonomic request flow manager contains three components: a work profiler, a controller and a gateway. For each node group, the ARFM function is implemented by one work profiler and one controller, each running on a node agent. In addition, a collection of gateways runs in the on demand routers (ODRs) for HTTP traffic and in the back-end servers for Internet Inter-ORB Protocol (IIOP) and JMS traffic. The gateways intercept and queue the incoming HTTP and IIOP requests, while the controller provides control signals, or directions, to the gateways and the placement controller. The work profiler continually estimates the computational requirements of the various kinds of requests, based on observations of the system in operation. Working together, these components properly prioritize incoming requests.

To modify the ARFM default settings in the administrative console page, click Operational policies > Autonomic managers > Autonomic request flow manager.

Procedure

  1. Modify the appropriate ARFM settings as described in the table following this procedure.
  2. Click OK or Apply when you have completed your changes.
  3. Click Save to save the changes to the master repository.
  4. Test the settings you have just defined and iterate as often as necessary to get the request flow performance that you want.

Example

The following table provides specific guidance for configuring each setting.
Field Purpose Tips for setting
Aggregation period Each ARFM gateway broadcasts aggregated statistics periodically, and this parameter specifies the period. The statistics reported by the gateways support: the runtime charting in the administrative console, the operation of ARFM controllers, the operation of the application placement controller, and the operation of work profilers.

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 by WebSphere Extended Deployment, 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, WebSphere Extended Deployment becomes less responsive to sudden changes in traffic intensities and patterns.

Control cycle length minimum This parameter defines how often the ARFM controller is activated. Controller activation is the process of evaluating inputs and producing new control settings as a result of the input received. The activation process for an ARFM controller is initiated when new statistics are received from one of its gateways AND the elapsed time since the previous activation is greater than or equal to the control cycle minimum length, or the controller has never activated before. This setting determines the control cycle length giving it a lower bound. For example, if you have just one ODR and set the aggregation period to 30 seconds and the control cycle minimum length to 60 seconds, you might find that one activation occurs at 12:00:00.0 and the next occurs 90.1 seconds later at 12:01:30.1 because the previous statistics arrival time was 12:00:59.9. To ensure a reliable control cycle of around 60 seconds, you would set the control cycle minimum length to 58 or 59 seconds.
Smoothing window This setting defines how sensitive the ARFM controller reaction is to the incoming gateway statistics, by allowing a concatenation of gateway statistics. For any gateway, its ARFM controller uses a running average of the last few statistics reports from that gateway. The smoothing window controls the number of reports that are combined.

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.

Maximum queue length

This parameter is used to bound the length of each ARFM queue to a maximum number of requests that may 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.

A lower parameter in this field increases the possibility that a request will be rejected due to short-term traffic bursts, while a higher parameter in this field may allow requests to linger longer in the queues. Queued requests consume memory. The default setting is 1000, but you may want to experiment with this setting to find the one that is a best match for your environment.

CPU overload protection

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 CPU 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 may be exceeded briefly.

Higher values give better resource utilization; lower values give more robust operation. Real load is noisy and variable. The performance management techniques in WebSphere Extended Deployment 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 CPU utilization than configured. Operation with one application server at 100% CPU utilization for multiple minutes has been observed to break some internal communication mechanisms, to the detriment of many features.

This setting should match the natural speed estimate target CPU utilization setting below. If you change one, you should change the other. The default for each is 90%.

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

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

Memory 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. The default is 95%.. .

Request rejection policy

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

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

What to do next

Use the WebSphere Extended Deployment 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 Extended Deployment.




Related tasks
Configuring speed factors in multiple tier configurations
Related reference
Administrative roles and privileges
Task topic    

Terms of Use | Feedback

Last updated: Nov 30, 2007 3:59:37 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todtunearfm.html