Apesar de não ser normalmente necessário nem recomendado, o ARFM (Autonomic Request Flow Manager) pode ter um ajuste fino, alterando-se as configurações padrão no console.
O Autonomic Request Flow Manager contém três componentes: um gerenciador de perfis de trabalho, um controlador e um gateway. Para cada grupo de nós, a função do ARFM é implementada por um gerenciador de perfis de trabalho e um controlador, cada um deles em execução em um agente do nó. Além disso, uma coleção de gateways são executados nos ODRs (On Demand Routers) para tráfego HTTP e nos servidores backend para tráfego IIOP e JMS. Os gateways interceptam e colocam em fila os pedidos de HTTP e IIOP de entrada, enquanto o controlador fornece sinais de controle, ou instruções, para os gateways e o controlador de posicionamento. O gerenciador de perfis de trabalho estima continuamente os requisitos computacionais dos vários tipos de pedidos, com base nas observações do sistema em operação. Trabalhando juntos, esses componentes priorizam apropriadamente os pedidos que chegam.
Campo | Utilizado para | Dicas para configurar |
Período de Agregação | Cada gateway ARFM difunde estatísticas agregadas periodicamente e esse parâmetro especifica o período. As estatísticas relatadas pelos gateways suportam:
|
Ao configurar o período de agregação, assegure que o valor seja alto o suficiente para permitir a coleta de um número suficiente de amostras de desempenho. Amostras são coletadas pelo(s) gateway(s) para cada pedido. Algumas centenas de amostras são necessárias para produzir uma boa medida estatística. Utilizando um exemplo, pedidos associados a uma classe de serviço são executados em 250 milissegundos e, em média, 10 pedidos são executados simultaneamente. (O valor de simultaneidade é calculado automaticamente pelo WebSphere Extended Deployment, com base no tamanho do cluster e nos recursos do ambiente. O valor de simultaneidade pode ser visto nos painéis de visualização, sob a categoria Operações do Tempo de Execução no console). Como resultado, a classe de serviço manipulará, aproximadamente, 40 pedidos por segundo. Assim, definir o valor do período de agregação para 15 segundos resultará na coleta de 600 amostras para cada período de agregação. As métricas fornecidas por uma pesquisa de amostra de 600 são úteis e confiáveis. Definir um valor de período de agregação muito baixo resultará em métricas de desempenho não confiáveis. As métricas de desempenho derivadas de poucas amostras têm mais interferências e são menos confiáveis do que um tamanho de amostra maior. Como o controlador do ARFM é ativado quando novas estatísticas são produzidas, definir um valor de período de agregação muito longo resulta em uma recomputação menos freqüente das configurações de controle. Assim, o WebSphere Extended Deployment torna-se menos responsivo a alterações inesperadas nas intensidades e padrões de tráfego. |
Duração Mínima do Ciclo de Controle | Esse parâmetro define com que freqüência o controlador do ARFM é ativado. A ativação do controlador é o processo de avaliar entradas e produzir novas configurações de controle da entrada recebida. O processo de ativação de um controlador de ARFM é iniciado quando novas estatísticas são recebidas de um de seus gateways e o tempo decorrido desde a última ativação é maior ou igual à duração mínima do ciclo de controle ou o controlador nunca foi ativado antes. | Essa definição determina a duração do ciclo de controle, fornecendo-lhe uma ligação mais baixa. Por exemplo, se você tiver somente um ODR e definir o período de agregação para 30 segundos e a duração mínima do ciclo de controle para 60 segundos, você pode descobrir que uma ativação ocorrerá às 12:00:00,0 e a próxima ocorrerá 90,1 segundos depois, às 12:01:30,1, pois a hora de chegada da estatística anterior era 12:00:59,9. Para assegurar um ciclo de controle confiável de, aproximadamente, 60 segundos, você deve definir a duração mínima do ciclo de controle para 58 ou 59 segundos. |
Janela de Suavização | Essa configuração define a sensibilidade da reação do controlador do ARFM em relação às estatísticas que chegam do gateway, permitindo uma concatenação das estatísticas do gateway. Para qualquer gateway, o controlador do ARFM utiliza uma média de execução dos últimos relatórios de estatísticas desse gateway. A janela de suavização controla o número de relatórios que são combinados. | Uma definição de janela de suavização baixa tornará o controlador mais sensível e permitirá uma reação mais rápida. No entanto, um parâmetro baixo também criará uma reação de sensibilidade a interferência, ou anomalias, nos dados. Recomenda-se que o produto da janela de suavização e o período de agregação sejam praticamente iguais à duração real do ciclo de controle, que, às vezes, pode ser ligeiramente maior do que a duração mínima configurada do ciclo de controle. |
Comprimento Máximo da Fila | Esse parâmetro é utilizado para ligar a duração de cada fila do ARFM a um número máximo de pedidos que podem ser mantidos na fila.
O ARFM divide todo o tráfego que chega em fluxos e tem uma fila separada para cada fluxo.
Particularidades dos fluxos incluem pedidos que:
|
Um parâmetro mais baixo nesse campo aumenta a possibilidade de um pedido ser rejeitado devido a intermitências de tráfego de pouca duração, enquanto que um parâmetro mais alto nesse campo pode permitir que pedidos fiquem mais tempo nas filas. Pedidos enfileirados consomem memória. A definição padrão é 1000, mas você pode querer experimentar essa definição para encontrar a melhor correspondência para seu ambiente. |
Utilização Máxima da CPU | O ARFM fornece proteção contra sobrecarga, além de seus recursos de priorização. Um ARFM colocará pedidos em fila em seus gateways para evitar sobrecarregar os servidores de aplicativos. Para esse release, a carga é determinada em termos de utilização de CPU na primeira camada dos servidores de aplicativos. O parâmetro de utilização máxima de CPU indica ao ARFM até que ponto carregar os servidores. Durante condições graves de pico, esse limite de utilização pode ser ligeiramente excedido. |
Valores mais altos fornecem melhor utilização de recursos; valores mais baixos fornecem uma operação mais robusta. A carga real é variável e contém interferência. As técnicas de gerenciamento de funcionamento no WebSphere Extended Deployment reagem a alterações na carga, mas com algum retardo de tempo. Durante o tempo de reação, o sistema pode operar fora de sua região configurada; isso inclui ter maior utilização de CPU do que a quantidade configurada. Observou-se que a operação com um servidor de aplicativos a 100% de utilização da CPU por vários minutos interrompe alguns mecanismos internos de comunicação, resultando em detrimento de muitos recursos. Essa definição deve corresponder à definição de utilização de CPU de destino estimada de velocidade natural abaixo. Se você alterar uma, deve alterar a outra. O padrão de cada é 90 (por cento). O gerenciamento de desempenho nesse release do WebSphere Extended Deployment não funciona bem se a primeira camada das máquinas do servidor de aplicativos forem carregadas com outro trabalho além de pedidos do WebSphere que chegam via HTTP através do ODRs. Essa configuração afeta a posição dos aplicativos. Se a demanda prevista total estiver acima do limite máximo de utilização da CPU, o controlador de posicionamento reduzirá uniformemente a demanda de todos os clusters dinâmicos antes de calcular a melhor posição. |