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

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

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 TOTVS | Broker.

São consideradas apenas as conexões que passam pelo Broker. Isto é, se um usuário se conectar sem utilizar o TOTVS | Broker, esta conexão não será levada em consideração pelo algoritmo de balanceamento.

Supondo inicialmente que nenhum usuário esteja conectado.

A imagem abaixo mostra as conexões após um usuário entrar 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 conectar irá ou para o servidor 2 ou para o 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 crie uma nova aba MDI criará uma nova conexão com um servidor.

Na tela abaixo, o usuário se conectou no servidor 2 no módulo SIGAADV, e abriu uma rotina de "Consulta Genérica de Cadastro". Portanto, aparecem 2 conexões para o servidor 2 na tela do broker.

Método de balanceamento sequencial (round robin)

Este método redireciona cada nova conexão de Smartclient para um servidor que consta na tabela de servidores do TOTVS | Broker em ordem sequencial.

São consideradas apenas as conexões que passam pelo TOTVS | Broker. Isto é, se um usuário se conectar sem utilizar o TOTVS | Broker, esta nova conexão não será levada em consideração pelo algoritmo de balanceamento.

Supondo uma configuração com 3 servidores, e inicialmente nenhum usuário conectado, a primeira conexão irá para o servidor 1, a segunda para para o servidor 2, a terceira para o servidor 3, a quarta volta para o servidor 1, a quinta para o servidor 2, e assim por diante

Tela inicial, sem usuários conectados.

Tela do TOTVS | Broker com o primeiro usuário conectado, ainda  na tela de menu do Smartclient, após conexão no módulo SIGMDI.

Tela do TOTVS | Broker após o usuário executar uma Consulta Genérica de Cadastro. A nova aba MDI abera consumiu uma nova conexão. Como o balanceamento é round robin, esta nova conexão foi para o servidor 2, que era o próximo na sequência na tabela de servidores do TOTVS | Broker.

O próximo servidor na sequência é o servidor 3. Então uma nova aba MDI aberta, ou um novo Smartclient iniciado vai abrir uma conexão com o servidor 3.

Tela do TOTVS | Broker após a abertura de um novo Smartclient. Usando o servidor 3, como previsto.

Para efeito de teste, este último Smartclient aberto, que utiliza o servidor 3, será fechado.

Tela após o fechamento deste Smartclient.

O servidor 3 agora está com zero conexões. Mesmo assim o próximo Smartclient a ser iniciado irá se conectar ao servidor 1, que é o próximo na sequência.

Como esperado, o novo Smartclient se conectou ao servidor 1, apesar do servidor 3 não estar sendo usado por nenhum Smartclient (está com zero conexões).

O próximo Smartclient a se conectar ainda não vai se conectar ao servidor 3, e sim ao servidor 2, que é o próximo na sequência.

Como esperado, o novo Smartclient se conectou ao servidor 2.

Agora, o próximo Smartclient a se conectar irá usar o servidor 3, que é o próximo na sequência

Confirmado, novo Smartclient se conectou no servidor 3.

Método de balanceamento por consumo de memória

Este método direciona cada nova conexão de Smartclient para o servidor com menor consumo de memória, como informado pelo monitoramento ativo dos servidores.

Mesmo as conexões que não passam pelo TOTVS | Broker afetam este método de balanceamento, pois a métrica utilizada não depende do TOTVS | Broker, mas sim do consumo de memória de cada servidor.

Tela inicial sem nenhum usuário passando pelo TOTVS | Broker.

O consumo de memória pelos servidores é bastante parecido, mas o servidor 2 tem o menor consumo: 33.966.

Então a primeira conexão de Smartclient a ser feita vai utilizar o servidor 2.

Tela do Broker após o primeiro usuário se conectar.

Como esperado, esse primeiro usuário se conectou no servidor 2.

O segundo usuário vai se conectar no servidor 3, que agora apresenta o menor consumo de memória entre os 3 servidores configurados.

Tela do Broker após a conexão do segundo usuário.

Correto, o segundo usuário se conectou no servidor 3.

O próximo usuário agora com certeza vai se conectar no servidor 1, que está usando muito menos memória que os outros 2 servidores.

Tela do Broker após a conexão do terceiro usuário.

Certo, o terceiro usuário se conectou no servidor 1.

Como o servidor 1 ainda é o servidor com menor consumo de memória, o próximo usuário a se conectar ainda vai utilizar o servidor 1.

Correto, o quarto usuário se conectou com o o servidor 1, que tinha o menor consumo de memória entre os 3 servidores configurados.