Ocasionalmente, puede encontrar un comportamiento de prioridad de peticiones que no es el previsto. En este tema se describen algunas de las cosas comunes que se han de buscar cuando la prioridad del flujo de peticiones no funciona del modo previsto.
Acción | Realizada por |
Compruebe que se hayan creado las políticas de servicio. | En la consola administrativa, seleccione Políticas operativas > Políticas de servicio. Todas las políticas de servicio definidas actualmente se visualizan. Si la política de servicio no figura en la lista, configure una nueva política de servicio pulsando Nuevo. |
Compruebe que las políticas de servicio se apliquen a los URI de aplicación correctos. | En la consola administrativa, seleccione Políticas operativas
> Políticas de servicio > Seleccione una política de servicio existente.
Compruebe las clases de transacciones asignadas en el campo Clases de transacción.
Para crear una nueva clase de transacción, pulse Nuevo. Si no ve los miembros de la clase de transacción que está buscando, compruebe que no hayan sido asignados ya a otra política de servicio. Además, asegúrese de que la aplicación a que desea aplicar una política de servicio está desplegada en el entorno. |
La diferenciación del tiempo de respuesta resulta aparente a medida que el grupo de nodos alcanza su límite de capacidad, lo que se produce cuando todos los nodos del grupo de nodos están utilizándose al completo. En un entorno dinámico, el controlador de ubicación de aplicaciones inicia más instancias de aplicaciones para dar abasto a las peticiones de trabajo, y si es necesario, Tivoli Intelligent Orchestrator (TIO), si está instalado, puede añadir nodos adicionales al entorno. Si se encuentra en una situación en la que todo el trabajo se está tratando del mismo modo, entonces siga los pasos que se muestran en la tabla anterior para asegurarse de que su política se ha configurado correctamente.
Si el gestor de flujo de peticiones autónomo (ARFM) no reacciona lo suficientemente deprisa, lo que da como resultado un tiempo de respuesta lento para la prioridad de peticiones, puede que desee ajustar los valores de ARFM. Consulte Configuración del gestor de flujo de peticiones autónomo para obtener más información. Debe prestar una atención especial al valor de Longitud mínima del ciclo de control y asegurarse de que ha seleccionado un valor correcto.
ARFM calcula continuamente la cantidad de trabajo que requiere cada clase de transacción del sistema y se refina a medida que las peticiones entran en el sistema. Para asegurarse de que se ha optimizado ARFM, debe ejecutar el sistema durante períodos de tiempo importantes con cargas de trabajo muy diferentes. Esta fluctuación de trabajo, combinada con un tiempo de actividad importante, permite a ARFM ajustarse y proporcionar cálculos más precisos que evitarán situaciones problemáticas.
En el caso de que uno o más nodos continúen teniendo índices de uso extremadamente elevados, mientras el resto de los nodos funcionan cómodamente, es posible que desee ajustar el ARFM. Consulte Configuración del gestor de flujo de peticiones autónomo para obtener más información. Debe prestar una atención especial al valor de Utilización máxima de CPU y asegurarse de que ha seleccionado un valor menor del que actualmente está utilizando el nodo.
Compruebe que está agrupando de forma coherente las clases de transacciones. Por ejemplo, no se recomienda agrupar los URI con un valor de servicio discrecional o bajo en la misma clase de transacción que los URI que tienen un valor de política de servicio alto. Si se combinan las peticiones con demandas muy diferentes en la misma clase de transacción ARFM genera cálculos imprecisos. Para modificar las clases de transacción, seleccione Políticas operativas > Políticas de servicio > Seleccione una política de servicio existente y compruebe en el campo de clase de transacción que está realizando las agrupaciones de forma coherente.
El sistema funciona tal y como se ha diseñado. Load Balancer intenta igualar el tiempo de respuesta en todos los nodos de programas de fondo de un clúster. Si un nodo es menos potente que otro, Load Balancer puede distribuir menos trabajo al nodo menos potente de modo que el tiempo de respuesta sea parecido al tiempo de respuesta de un nodo más rápido.