Use this panel to configure the autonomic request flow
manager (ARFM). The ARFM manages incoming messages for applications:
it determines whether and when to allow the messages to be serviced
by middleware servers. For HTTP and Session Initiation Protocol (SIP)
traffic, the management actions take place in the on demand routers.
For Java Message Service (JMS)
and Internet Inter-ORB Protocol (IIOP) messages, the management actions
take place in the application servers.
To view this administrative console page, click .
The autonomic request flow manager (ARFM) contains two parts: a
controller and a gateway. The ARFM function is implemented for each
cell by a controller plus a collection of gateways in the on demand
routers (ODRs). The gateways intercept and queue the incoming requests,
while the controller provides control signals, or directions, to the
gateways and the placement controller. The components work together
to prioritize incoming requests.
![[8.5.5.3 or later]](./images/ng_v8553.gif)
To manage HTTP traffic, you can use a node-based
algorithm. To enable the node-based ARFM, set the cell custom property arfmQueueMode.
With the node-based ARFM, queuing and CPU overload protection is performed
at the node level. There is no separate controller and gateway involved.
Depending on your administrative role, you are allowed specific
privileges when you configure the autonomic request flow manager.
This list shows the administrative roles and privileges for configuring
the autonomic request flow manager:
- Monitor
- Can view the information.
- Operator
- Can view the information on the configuration tab.
- Configurator
- Can change the configuration.
- Administrator
- Has all privileges.
Enabling security When security is enabled,
some fields are not editable without appropriate security authorization.
Aggregation period
Each ARFM gateway broadcasts aggregated statistics periodically,
and this field specifies the period. The default value is 5 seconds.
This property does not apply to node-based
ARFM.
Gateway support reports the following statistics:
- The runtime charting in the WebSphere® administrative
console.
- The operation of the ARFM controllers.
- The operation of the application placement controller.
When you set the aggregation period, set the value high enough
to support the collection of a sufficient number of performance samples.
Gateways collect samples for each request. To produce a good statistical
measure, a few hundred samples are necessary. For example, requests
that are 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. You can see the concurrency value on the visualization
panels under Runtime operations in the administrative
console.
As a result, the service class handles about 40 requests per second.
Setting the aggregation period value to 15 seconds results in the
collection of 600 samples for each aggregation period. The metrics
that are provided by a 600 sample survey are useful and reliable.
Setting an aggregation period value too low results in unreliable
performance metrics. Performance metrics that are derived from fewer
samples are less reliable than a higher number of samples. Because
the ARFM controller is activated when new statistics are produced,
setting an aggregation period value too long results in less frequent
recomputation of the control settings. Therefore, the product becomes
less responsive to sudden changes in traffic intensity and patterns.
Smoothing window
Defines how sensitive the ARFM controller reaction is to
the incoming gateway statistics, by allowing a concatenation of gateway
statistics. The default value is 12.
This property does not apply to node-based
ARFM.
The ARFM controller of any gateway uses a running average of the
last few statistic 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 supports quicker
reaction. However, a low setting also creates a sensitive reaction
to noise, or anomalies in the data.
The product of the smoothing window and the aggregation period
is approximately the same as the actual control cycle length, which
sometimes is slightly greater than the configured control cycle minimum
length.
Maximum queue length
Bounds the length of each ARFM queue to a maximum number
of requests that are possibly held in queue.
The ARFM has a separate queue for each combination of on demand
routers, node groups, service classes, and deployment targets. When
a request arrives and the queue is full, the request is rejected.
A lower parameter in this field increases the possibility that a request
is rejected due to short-term traffic bursts, while a higher parameter
allows requests to linger longer in the queues. Queued requests use
memory. The default setting is 1000, but test this
setting to determine which one best matches your environment.
The node-based ARFM has a separate queue
for each node and each cluster. This property refers to the total
number of queued requests allowed.