🧾 Resumo

Este artigo consolida a recomendação prática da Mastersiga para dimensionamento de usuários simultâneos por AppServer (slave) e balanceamento de carga no TOTVS Protheus, com uma matriz de referência por perfil de ambiente e um checklist operacional para validação em produção/homologação.

🎯 Aplicabilidade

Use este conteúdo quando houver:

• 📈 Crescimento de usuários simultâneos.

• 🐢 Lentidão recorrente no Protheus (SmartClient/WebApp).

• ⚖️ Necessidade de balancear conexões entre slaves (AppServers).

• 🔌 Concorrência com integrações REST/WebServices.

• 🧠 Planejamento/expansão de capacidade e arquitetura.

✅ Pré-requisitos

• 🔐 Acesso ao appserver.ini e às configurações de rede/balanceamento (quando aplicável).

• 🖥️ Inventário básico do ambiente: CPU/RAM/Disco, versão do Protheus, WebApp/SmartClient, DBAccess e banco.

• 📊 Dados de uso: média e pico de usuários simultâneos e horários críticos.

• 🧩 Mapeamento de rotinas pesadas (fechamentos, relatórios grandes, integrações).

🛠️ Passo a passo

1) 📌 Defina a referência inicial (ponto de partida)

Como orientação prática para iniciar o dimensionamento:

• 80 a 120 usuários simultâneos por instância (AppServer/slave) em cenários predominantemente interativos.

⚠️ Essa referência precisa ser validada por monitoração, pois o limite real depende do perfil de uso e recursos.

2) 🧩 Classifique o perfil do ambiente (matriz Mastersiga)

Use a matriz abaixo como guia inicial de “usuários simultâneos por slave”:

✅ Regra prática: se o ambiente tem picos pesados ou integrações concorrendo, reduza o número por slave e/ou separe instâncias por perfil (próximo passo).

3) ⚖️ Ajuste o balanceamento (peso por conexões)

Em ambientes com balanceamento por configuração de rede (ex.: ServerNetwork), os parâmetros de “conexões” costumam funcionar como peso de distribuição entre instâncias (ex.: 60/40), e não como “limite rígido”.

📌 Boas práticas:

• ✅ Distribuir pesos conforme capacidade do servidor (CPU/RAM) e perfil da instância.

• ✅ Evitar concentrar “rotinas pesadas” e “serviços” na mesma instância que atende usuário.

4) 🔌 Separe instâncias por perfil (recomendação Mastersiga)

Quando há concorrência entre usuário e serviços, a melhor prática é separar:

• 👤 Interativo: AppServer(s) dedicados para SmartClient/WebApp (usuário final).

• 🌐 REST/WebServices: AppServer(s) dedicados para integrações.

• 🕒 Jobs/Agendamentos: instâncias dedicadas quando houver picos de processamento.

✅ Isso reduz disputa por CPU/threads/memória e melhora previsibilidade.

5) 🧯 Habilite controles de proteção contra saturação

Para evitar degradação em cascata:

• 🧠 Defina limite de memória do AppServer (ex.: ServerMemoryLimit) para recusar novas conexões ao atingir o teto.

• 🧵 Revise parâmetros relacionados a threads/ThreadPool quando houver uso intensivo de REST.

• ⏱️ Planeje janelas de fechamentos/rotinas grandes e evite concorrência com horários críticos.

6) ✅ Checklist operacional de validação (antes/depois)

Use este checklist em mudanças de carga/arquitetura:

1. 📋 Inventário

   • média/pico de usuários simultâneos

   • horários críticos

   • rotinas mais executadas

   • integrações REST/WebServices e jobs

2. 📊 Capacidade

   • CPU/RAM/IO do AppServer, DBAccess e banco

   • identificar gargalo real (CPU, memória, disco, BD)

3. 🧱 Arquitetura

   • separar interativo x serviços x jobs quando necessário

   • revisar pesos do balanceamento

4. 🧯 Proteções

   • ServerMemoryLimit

   • threads/ThreadPool

   • timeouts adequados

5. 🧪 Validação

   • testar login, rotinas críticas, emissão, consultas, relatórios e integrações em horário de pico

6. 📝 Registro

   • documentar configuração final e evidências (prints/logs)

❌ Erros comuns

• 🚫 Definir “usuários por slave” sem considerar rotinas pesadas e integrações concorrendo.

• 🚫 Aumentar número de slaves sem avaliar gargalo de DBAccess/banco.

• 🚫 Misturar REST/WebServices e usuários interativos na mesma instância em ambientes com alto volume.

• 🚫 Não ter limites de proteção (memória/threads), gerando travamentos em cascata.

• 🚫 Balancear só “por quantidade”, ignorando capacidade real do servidor.

❓ FAQ

❓ Existe um número ideal fixo de usuários por slave?
✅ Não. Existe uma referência inicial, mas o ideal depende de hardware e perfil de uso.

❓ O que fazer quando o ambiente tem integrações concorrendo?
✅ Separar instâncias: interativo vs REST/WebServices (e jobs, se aplicável).

❓ Quando devo considerar DBAccess distribuído?
✅ Quando há alto volume de conexões simultâneas e sinais de gargalo no acesso ao banco — como referência interna, priorizar arquitetura distribuída em cenários acima de ~500 conexões simultâneas.

❓ Balanceamento por “Connections” é limite?
✅ Normalmente não. Em geral funciona como peso de distribuição.

🔗 Referências

• 📘 Documentação/Boas práticas TOTVS (dimensionamento e arquitetura Protheus) — consultar central oficial TOTVS conforme versão/release do cliente.

• 🧩 Guia interno Mastersiga: Plano Operacional POBALSLV01.xx (arquivado na gestão).