Histórico da Página
O
| Inclusão de trecho | ||||||
|---|---|---|---|---|---|---|
|
| Inclusão de trecho | ||||||
|---|---|---|---|---|---|---|
|
| SORT_METHOD | Descrição | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| CONNECTION | Balanceamento por número de conexões | ||||||||
| ROUND_ROBIN | Balanceamento Round Robin (RR) | ||||||||
| SERVER_MEMORY | Balanceamento por consumo de memória reportado pelo
| ||||||||
| SERVER_USERS | Balanceamento por número de usuários reportados pelo | ||||||||
| SERVER_THREADS | Balanceamento por número de threads reportado pelo
| ||||||||
| SERVER_CPU | Balanceamento por consumo de CPU reportado pelo
|
Obs.: o método SERVER_MEMORY é o padrão e não precisa ser especificado.
A especificação do método de balanceamento é feita pelo uso da chave SORT_METHOD na seção BALANCE_SMART_CLIENT_DESKTOP no arquivo de configuração do
| Inclusão de trecho | ||||||
|---|---|---|---|---|---|---|
|
Os métodos SERVER_MEMORY, SERVER_USERS, SERVER_THREADS e SERVER_CPU são efetivos apenas quando usados em conjunto com a opção de monitoramento ativo (SMARTCLIENT_ACTIVE ou SMARTCLIENT_SSL_ACTIVE).
Exemplo
Este exemplo utiliza o método de balanceamento pelo consumo de memória nos servidores.
| Sem Formato |
|---|
[BALANCE_SMART_CLIENT_DESKTOP]
...
...
SORT_METHOD=SERVER_MEMORY
...
...
|
Detalhes dos métodos de balanceamento
Método de balanceamento por conexões
Este método utiliza como métrica o número de conexões de Smartclient para cada servidor que consta na tabela de servidores do Broker.
São consideradas apenas as conexões que passam pelo Broker. Isto é, se um usuário se conecta (sem utilizar o Broker), está conexão não é levada em consideração.
Exemplo.
Supondo inicialmente que nenhum usuário está logado.
Agora, após um usuário se logar no sistema. Como o balanceamento está sendo feito pelo número de conexões, então o servidor que tiver o menor número de conexões será o escolhido. Como os 3 servidores possuem o mesmo número de conexões (zero), qualquer um deles poderá ser escolhido.
O servidor 1 foi o escolhido, porque era um dos que possuía menor quantidade de conexões.
O próximo usuário a se logar irá para o servidor 2 ou servidor 3.
Foi escolhido o servidor 2.
Agora, o próximo usuário a se conectar será obrigatoriamente direcionado ao servidor 3.
Confirmado, o terceiro usuário foi direcionado para o servidor 3.
Agora, para efeito de teste, o segundo usuário (servidor 2) fecha sua sessão com o sistema.
Certo, o servidor 2 agora aparece com zero conexões.
Portanto, o próximo usuário que se conectar irá ser direcionado ao servidor 2, que é o servidor com o menor número de conexões.
Certo, o novo usuário foi direcionado ao servidor 2.
Agora, um detalhe: este terceiro usuário se conectou no servidor 2 através da rotina SIGAMDI. Esta rotina possibilita abrir várias abas, cada aba acessando um módulo diferente. Importatante: cada aba aberta conta como uma nova conexão para o Broker.
Após o terceiro usuário (que se logou com SIGAMDI no servidor 2) abrir uma aba no módulo Ativo Fixo, a tela do broker ficará assim:
Isto é, o terceiro usuário, que se logou com SIGAMDI no servidor 2 e logo em seguida abriu uma aba no módulo Ativo Fixo, consumiu 2 conexões no Broker,
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas