Árvore de páginas

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 26 Próxima »

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

SORT_METHODDescrição
CONNECTIONBalanceamento por número de conexões
ROUND_ROBINBalanceamento sequencial (round robin)
SERVER_MEMORY

Balanceamento por consumo de memória reportado pelo TOTVS | Application Server

SERVER_USERS

Balanceamento por número de usuários reportados pelo TOTVS | Application Server

SERVER_THREADS

Balanceamento por número de threads reportado pelo TOTVS | Application Server

SERVER_CPU

Balanceamento por consumo de CPU reportado pelo TOTVS | Application Server

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


Exemplo: 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 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 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, com nenhuma usuário conectado.


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


Tela do 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 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.

Tela do 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 conertar 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.

  • Sem rótulos