Request prioritization problems

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

Request prioritization problems

Occasionally, you might encounter flow prioritization behavior that is unexpected. You can look for some common things when request flow prioritization is not working as expected.

HTTP requests are all discretionary
If your environment treats all of the incoming requests equally, you might not have a service policy defined and applied to the proper application module Uniform Resource Identifiers (URI). A best effort approach, also called discretionary, is the default policy. Take the following actions to ensure that the service policy is configured and applied:

Action Performed by
Verify that your service policies are created. From the administrative console, click Operational policies > Service policies. All of the currently defined service policies display. If you do not see your service policy listed, configure a new service policy by clicking New.
Verify that your service policies are applied to the proper application URIs. From the administrative console, click Operational policies > Service policies > Select an existing service policy. Verify the assigned transaction classes are in the Transaction Classes field. You can create a new transaction class by clicking New.
If you do not see the transaction class members you are looking for, check that they are not already assigned to another service policy. Also, ensure that the application to which you in applying a service policy to is deployed in your environment.

Slow response time for request prioritization

If the autonomic request flow manager (ARFM) is not reacting fast enough, resulting in slowed response time for request prioritization, then you can tune the ARFM settings. See Configure the autonomic request flow manager for more information. In particular, review the Set Control Cycle Length Minimum setting to ensure that a suitable value is selected.

CPU use remains at 100% on one or more back-end nodes

ARFM is continuously computing the amount of work each transaction class requires from the system and refining as requests come into the system. To ensure that the ARFM is optimized, run your system for significant periods of time with largely varying workloads. This fluctuation of work, combined with significant up time, allows ARFM to fine tune itself and provide more accurate estimates to avoid problem situations.
If one or more nodes remain at high use rates, while the remainder of the nodes are working comfortably, you might want to fine tune the ARFM. See Configure the autonomic request flow manager for more information. In particular, review Maximum CPU Utilization setting to ensure that you select a lesser value than your node is currently utilizing.
Verify that you are consistently grouping transaction classes. For example, do not group URIs with a discretionary, or low service value in the same transaction class as URIs with a high service policy value. Mixing requests with widely varying demands in the same transaction class causes the ARFM to produce inaccurate estimates. To modify your transaction classes, click Operational policies > Service policies > Select an existing service policy and verify the transaction class field to ensure consistent groupings.

In a heterogeneous cell, not all the nodes in the cell are used equally

The system is working as designed. The load balancer tries to equalize response time on all the back-end nodes in a cluster. If one node is less powerful than another, then the load balancer might distribute less work to the less powerful node so that response time can be similar to the response time from a faster node.

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 concepts

Operational policies

Related tasks

Configure the autonomic request flow manager

Action	Performed by
Verify that your service policies are created.	From the administrative console, click Operational policies > Service policies. All of the currently defined service policies display. If you do not see your service policy listed, configure a new service policy by clicking New.
Verify that your service policies are applied to the proper application URIs.	From the administrative console, click Operational policies > Service policies > Select an existing service policy. Verify the assigned transaction classes are in the Transaction Classes field. You can create a new transaction class by clicking New. If you do not see the transaction class members you are looking for, check that they are not already assigned to another service policy. Also, ensure that the application to which you in applying a service policy to is deployed in your environment.