Aunque generalmente no es necesario ni está recomendado el gestor de flujos de peticiones autónomo, ARFM, se puede ajustar con precisión modificando los valores por omisión de la consola.
El gestor de flujo de peticiones autónomo contiene tres componentes: un perfilador de trabajo, un controlador y una pasarela. Para cada grupo de nodos, la función ARFM la implementa un perfilador de trabajo y un controlador, cada uno de los cuales se ejecuta en un agente de nodo. Asimismo, se ejecuta una colección de pasarelas en los Direccionadores On Demand (ODR) para el tráfico HTTP y en los servidores de programa de fondo para el tráfico IIOP y JMS. Las pasarelas interceptan y ponen en cola las peticiones HTTP e IIOP de entrada, mientras que el controlador proporciona las señales de control, o indicaciones, a las pasarelas y al controlador de ubicación. El perfilador de trabajo continuamente calcula los requisitos de sistema de los diferentes tipos de peticiones, basados en observaciones del sistema cuando está en funcionamiento. El funcionamiento conjunto de estos componentes permite establecer correctamente las prioridades de las peticiones de entrada.
Campo | Utilizado por | Sugerencias para su definición |
Periodo de adición | Cada pasarela del ARFM divulga periódicamente estadísticas globales y este parámetro especifica el
periodo. Entre las estadísticas proporcionadas por las pasarelas se encuentran:
|
Cuando establezca el periodo de adición, asegúrese de que el valor sea lo suficientemente alto como para permitir la recopilación de un número suficiente de muestras de rendimiento. Las pasarelas recopilan las muestras de cada petición. Para producir medidas estadísticas adecuadas se necesitan unos cuantos cientos de muestras. Por ejemplo, las peticiones asociadas a una clase de servicio se ejecutan en 250 milisegundos y como media se ejecutan 10 peticiones de forma simultánea. WebSphere Extended Deployment calcula automáticamente el valor de concurrencia basándose en el tamaño del clúster y en los recursos del entorno. El valor de concurrencia puede verse en los paneles de visualización, bajo la categoría Operaciones de tiempo de ejecución de la consola. Como resultado, la clase de servicio manejará unas 40 peticiones por segundo. Por lo tanto, si se establece el valor del periodo de adición en 15 segundos se recopilarán 600 muestras por cada periodo de adición. Las métricas proporcionadas por un sondeo de 600 muestras son útiles y fiables. Si se establece un periodo de adición demasiado bajo las métricas de rendimiento no serán fiables. Las métricas de rendimiento derivadas de un número bajo de muestras tienen mucho más ruido y son menos fiables que las de un tamaño de muestra mayor. Como el controlador del ARFM se activa cuando se producen nuevas estadísticas, si se establece un valor del periodo de adición demasiado largo los valores de control se volverán a calcular con menor frecuencia. Por lo tanto, WebSphere Extended Deployment será menos sensible a los cambios bruscos que se produzcan en las intensidades y patrones del tráfico. |
Longitud mínima del ciclo de control | Este parámetro define la frecuencia con que se activa el controlador del ARFM. La activación del controlador es el proceso de evaluar las entradas y producir nuevos valores de control como resultado de la entrada recibida. El proceso de activación de un controlador del ARFM se inicia cuando se reciben nuevas estadísticas de una sus pasarelas y el tiempo transcurrido desde la activación anterior es mayor o igual que la longitud mínima del ciclo de control, o el controlador nunca se ha activado anteriormente. | Este valor determina la longitud del ciclo de control con un límite inferior. Por ejemplo, si sólo dispone de un ODR y establece el periodo de adición en 30 segundos y la longitud mínima del ciclo de control en 60 segundos, es posible que se encuentre con que a las 12:00:00.0 se produce una activación y 90,1 segundos más tarde la siguiente, a las 12:01:30.1, porque la hora de llegada de las estadísticas anteriores era a las 12:00:59.9. Para garantizar un ciclo de control fiable de unos 60 segundos, debería establecer la longitud mínima del ciclo de control en 58 ó 59 segundos. |
Ventana de suavizado | Este valor define la sensibilidad de reacción del controlador del ARFM ante las estadísticas de entrada de la pasarela, permitiendo la concatenación de estadísticas de la pasarela. En cada pasarela, su controlador del ARFM utiliza una media móvil de algunos de los últimos informes de estadísticas de esa pasarela. La ventana de suavizado controla el número de informes que se combinan. | Un valor bajo de ventana de suavizado hará que el controlador sea más sensible y permitirá una reacción más rápida. Sin embargo, un parámetro bajo también creará una reacción más sensible al ruido, o anomalías, en los datos. Se recomienda que el producto de la ventana de suavizado y el periodo de adición sea aproximadamente el mismo que la longitud del ciclo de control real, que será a veces ligeramente superior que la longitud mínima del ciclo de control configurada. |
Longitud máxima de cola | Este parámetro se utiliza para limitar la longitud de cada cola del ARFM a un número máximo de peticiones que
pueden mantenerse en la cola. ARFM
divide todo el tráfico de entrada en flujos y tiene una cola diferente para cada flujo. Los flujos particulares incluyen peticiones que:
|
Un parámetro más bajo en este campo aumenta las posibilidades de que se rechace una petición como consecuencia de aumentos de tráfico de corta duración, mientras que un parámetro más alto en este campo podría hacer que las peticiones permaneciesen más tiempo en las colas. Las peticiones en cola consumen memoria. El valor por omisión es 1000, pero puede probar con otros valores para encontrar el más adecuado para su entorno. |
Utilización máxima de CPU | El ARFM proporciona protección contra sobrecarga, además de sus capacidades de establecer prioridades. Un ARFM pondrá en cola las peticiones en sus pasarelas para evitar sobrecargar los servidores de aplicaciones. En este release, la carga se determina por la utilización de CPU en el primer nivel de servidores de aplicaciones. El parámetro de utilización máxima de CPU indica al ARFM la cantidad de carga que debe permitir en los servidores. En situaciones con grandes picos este límite de utilización podría superarse por poco tiempo. |
Con los valores más altos se obtienen una utilización mejor de los recursos y los valores más bajos presentan un funcionamiento más potente. La carga real es variable y ruidosa. Las técnicas de gestión de rendimiento de WebSphere Extended Deployment reaccionan a los cambios de la carga pero con algún retraso. Durante el período de tiempo de reacción, es posible que el sistema funcione fuera de la región configurada, esto incluye un uso de CPU por encima del configurado. Se ha observado que el funcionamiento con un servidor de aplicaciones cuyo uso de CPU es del 100% durante varios minutos interrumpe algunos mecanismos de las comunicaciones internas, resultando en un detrimento de muchas funciones. Este valor debe coincidir con el valor de utilización de CPU de destino para cálculo de velocidad natural mencionado a continuación. Si cambia uno, debe cambiar el otro. El valor por omisión de cada uno es de 90 (por ciento). La gestión de rendimiento de este release de WebSphere Extended Deployment no funciona bien si el primer nivel de las máquinas del servidor de aplicaciones se cargan con otro trabajo aparte de las peticiones de WebSphere que llegan mediante HTTP a través de los ODR. Este valor afecta a la ubicación de aplicaciones. Si la demanda total prevista está por encima del límite máximo de utilización de la CPU, el controlador de ubicación reduce uniformemente la demanda de todos los clústeres dinámicos antes de calcular la mejor ubicación. |