O TOTVS | Broker suporta os métodos descritos abaixo para balancear as conexões oriundas de um :

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 TOTVS | Broker (appserver.ini).

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).

Este exemplo utiliza o método de balanceamento pelo consumo de memória nos servidores.

[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: a cada aba que acessa uma rotina específica de um módulo, uma nova conexão com o servidor será aberta. Assim, a tela inicial do módulo (p.ex. SIGAADV, SIGAMDI) conta com uma conexão, e qualquer rotina escolhida que cri.

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,