Use este painel para configurar o gerenciador autônomo de fluxo de solicitações (ARFM). O ARFM gerencia mensagens recebidas para aplicativos: ele determina se e quando permitir que mensagens sejam entregues pelos servidores de middleware. Para tráfego HTTP e do Protocolo de Inicialização de Sessão (SIP), as ações de gerenciamento acontecem nos roteadores sob demanda. Para mensagens do Serviço de Mensagens Java (JMS) e do Internet Inter-ORB Protocol (IIOP), as ações de gerenciamento acontecem nos servidores de aplicativos.
Para visualizar essa página do console administrativo, clique em
.O ARFM (Gerenciador Autônomo de Fluxo de Pedidos) contém duas partes: um controlador e um gateway. A função ARFM é implementada, para cada célula, por um controlador além de uma coleta de gateways nos ODRs (On Demand Routers). Os gateways interceptam e colocam em fila os pedidos de entrada, enquanto o controlador fornece sinais de controle, ou instruções, para os gateways e o controlador de posicionamento. Os componentes funcionam juntos para priorizar pedidos de entrada.
Para gerenciar tráfego HTTP, é possível usar um algoritmo baseado em nó. Para ativar o ARFM baseado em nó, configure a propriedade customizada da célula arfmQueueMode.
Com o ARFM baseado em nó, a proteção de sobrecarga de CPU e enfileiramento é executada no nível do nó. Não há um controlador e um gateway separados envolvidos.
Dependendo de sua função administrativa, você terá permissão para privilégios específicos ao configurar o gerenciador autônomo de fluxo de solicitações. Esta lista mostra as funções e os privilégios administrativos para configurar o gerenciador autônomo de fluxo de pedidos:
Ativação de segurança Quando a segurança está ativada, alguns campos não são editáveis sem a autorização de segurança apropriada.
Cada gateway ARFM difunde estatísticas agregadas periodicamente e este campo especifica o período. O valor padrão é 5 segundos.
Esta propriedade não se aplica ao ARFM baseado em nó.
Ao configurar o período de agregação, configure o valor alto o bastante para suportar a coleção do número suficiente de amostras de desempenho. Os gateways coletam amostras para cada pedido. Para produzir uma boa medida estatística, algumas centenas de amostras são necessárias. Por exemplo, os 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 da simultaneidade é calculado automaticamente, baseado no tamanho do cluster e nos recursos do ambiente. É possível ver o valor de simultaneidade nos painéis de visualização em Operações de Tempo de Execução no console administrativo.
Por isso, a classe de serviço manipulará cerca de 40 pedidos por segundo. A configuração do valor do período de agregação para 15 segundos resulta na coleta de 600 amostras para cada período de agregação. As métricas que são fornecidas por uma pesquisa de opinião de 600 amostras são úteis e confiáveis.
A configuração de um valor do período de agregação muito baixa resultará em métricas de desempenho não confiáveis. As métricas de desempenho que são derivadas de menos amostras são menos confiáveis que um número maior de amostras. 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. Portanto, o produto se torna menos responsivo a mudanças repentinas nos padrões e na intensidade do tráfego.
Define com que freqüência o controlador ARFM é ativado. O valor padrão é 59 segundos.
Esta propriedade não se aplica ao ARFM baseado em nó.
Ativação do controlador é o processo de avaliar entrada e produzir novas configurações de controle como resultado da entrada recebida. O processo de ativação para um controlador ARFM é iniciado quando novas estatísticas vêm de um de seus gateways e o tempo decorrido desde a ativação anterior é maior que ou igual ao comprimento mínimo do ciclo de controle ou se o controlador nunca foi ativado.
Define a sensibilidade da reação do controlador do ARFM em relação às estatísticas do gateway de entrada, permitindo uma concatenação das estatísticas do gateway. O valor padrão é 12.
Esta propriedade não se aplica ao ARFM baseado em nó.
O controlador ARFM de qualquer gateway utiliza uma média de execução dos últimos relatórios de estatísticas desse gateway. A janela de uniformização controla o número de relatórios combinados. A configuração de uma janela de uniformização inferior torna o controlador mais sensível e suporta uma reação mais rápida. No entanto, uma configuração inferior também cria uma reação sensitiva a desorganização ou anomalias nos dados.
O produto da janela de uniformização e do período de agregação é aproximadamente o mesmo que a duração do ciclo de controle real, que às vezes é um pouco maior que a duração mínima do ciclo de controle configurado.
Liga o comprimento de cada fila ARFM a um número máximo de pedidos possivelmente mantidos na fila.
O ARFM possui uma fila separada para cada combinação de On Demand Routers, grupos de nós, classes de serviço e destinos de implementação. Quando um pedido chega e a fila está cheia, ele é rejeitado. Um parâmetro inferior nesse campo aumenta a possibilidade de que um pedido seja rejeitado devido a bursts de tráfego a curto prazo, enquanto um parâmetro superior permite que os pedidos fiquem mais nas filas. Solicitações enfileiradas usam memória. A configuração padrão é 1000, mas teste essa configuração para determinar qual corresponde melhor a seu ambiente.
O ARFM baseado em nó possui uma fila separada para cada nó e cada cluster. Essa propriedade se refere
ao número total de solicitações enfileiradas permitidas.
Especifica a porcentagem máxima do tamanho de heap a ser utilizado para cada servidor de aplicativos. Esta propriedade se aplica a mensagens de HTTP e SIP (Session Initiation Protocol). O padrão é 100%.
Especifica uma porcentagem máxima de uso de CPU para nós de middleware. O ARFM considera o cluster inteiro como um todo ao calcular o uso de CPU. Quando o uso de CPU excede essa porcentagem, o cluster é considerado sobrecarregado. O ARFM considera o cluster inteiro como um todo ao calcular o uso de CPU. O padrão é 90%.
O ARFM baseado em nó considera o uso da CPU em uma base nó por nó. Quando o uso de CPU excede a porcentagem de uso máximo, o nó é considerado sobrecarregado. O padrão é 90%.
Uma política de rejeição evita que uma CPU seja sobrecarregada rejeitando mensagens HTTP ou SIP que chegam e que não fazem parte de diálogos ou sessões preexistentes.