Intelligent Management: request prioritization problems
Occasionally, we 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 the environment treats all of the incoming requests equally, we 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... 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 your service policies are applied to the proper application URIs. From the administrative console, click... Operational policies > Service policies > existing service policy
Verify that the assigned transaction classes are in the transaction classes field. Create a transaction class by clicking New.
If we do not see the transaction class members we are looking for, check that they are not already assigned to another service policy. Also, ensure that the application we 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 we 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 > existing service policy
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:
Operational policies Configure the autonomic request flow manager