Intelligent Management: 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:

Table 1. Service policy configurations . The following table outlines the actions required to ensure the service policy is configured correctly.
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 that the assigned transaction classes are in the transaction classes field. You can create a 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 you are applying a service policy to is deployed in your environment.

Differentiation of a service policy not occurring

Differentiation in response time becomes apparent as the node group approaches its maximum CPU usage threshold, which occurs when all of the nodes in the node group are fully used. In a dynamic environment, the application placement controller can be configured to start more application instances to keep up with the work requests and reduce the load on individual servers.

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

ARFM is continuously computing the load of each transaction class on the system and continuously optimizes the load distribution. To ensure that the ARFM is optimized, allow ARFM to gather load information for a period of time so that it can fine-tune itself.

Verify that you are consistently grouping transaction classes. For example, avoid grouping URIs with long service times in the same transaction class as URIs with low service times. 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.