Intelligent Management: request prioritization problems

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

HTTP requests are all discretionary

If wer 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:

following table outlines the actions required to ensure the service

Action	Performed by
Verify that the service policies are created.	From the console, click Operational policies > Service policies. All of the currently defined service policies display. If we do not see the service policy listed, configure a new service policy by clicking New.
Verify that the service policies are applied to the proper application URIs.	From the console, click Operational policies > Service policies > Select an existing service policy. Verify that the assigned transaction classes are in the transaction classes field. We can create a transaction class by clicking New. If we 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 the 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 the 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.

Related concepts

Operational policies

Related tasks

Configure the autonomic request flow manager