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.
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. |
Differentiation in response time becomes apparent as the node group approaches its capacity limit, which occurs when all of the nodes in the node group are fully used In a dynamic environment, the application placement controller starts more application instances to keep up with the work requests, and if necessary Tivoli Intelligent Orchestrator, when installed, can add additional nodes into the environment. If you encounter a situation where all work is treated equally, then follow the steps in the previous table to ensure that your policy is properly configured.
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 Configuring 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.
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 Configuring 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.
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.
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.