Se o ERP está lento, o problema pode estar bem abaixo da tela do usuário.

Poucos sintomas são tão comuns (e tão negligenciados) quanto a lentidão em ambientes TOTVS. O usuário final reclama da tela travando, o gestor aperta o time de TI, e a área técnica tenta, sem sucesso, resolver com mais banda, reinstalar o client ou reiniciar o servidor. Mas, muitas vezes, o problema está em um lugar que quase ninguém olha: o dimensionamento do ambiente.

O que é o sizing de ambiente?
É o processo técnico de calcular, com precisão, a capacidade mínima e ideal da sua infraestrutura para suportar o ERP de forma estável, performática e escalável.

E é aqui que muitos projetos falham — não por falta de software, mas por infraestrutura subestimada.

1. O que deve ser considerado no sizing de ambiente TOTVS

Um bom sizing vai muito além da escolha de um servidor “forte”. Ele exige análise de diversas variáveis técnicas e operacionais, como:

• Volume de usuários simultâneos
• Distribuição geográfica da operação (filiais acessando remotamente)
• Módulos utilizados e sua complexidade (Financeiro? Faturamento? Fiscal?)
• Quantidade de documentos processados diariamente
• Volume histórico armazenado no banco de dados
• Integrações simultâneas com outras plataformas (CRM, BI, e-commerce)

A soma desses fatores define o que será necessário em termos de:

• CPU e núcleos reais (não apenas “núcleos virtuais”)
• Quantidade de memória RAM
• Performance de disco (IOPS — Input/Output Operations Per Second)
• Arquitetura de rede
• Topologia de camadas (aplicação, banco, terminal, etc.)

2. TOTVS Protheus e RM: características distintas, sizing diferente

Apesar de fazerem parte do mesmo ecossistema, o Protheus e o RM têm comportamentos muito diferentes — e exigências distintas de ambiente:

• Protheus

• Utiliza o AppServer como servidor de aplicação
• Alto consumo de CPU em processos pesados (ex: Faturamento, MRP)
• Necessita de tuning em arquivos de configuração (.ini)
• Altamente sensível à performance de disco para arquivos temporários e logs

• RM

• Baseado em arquitetura .NET
• Demanda maior atenção à versão do IIS e .NET Framework
• Pode exigir múltiplas instâncias do AppServerRM em ambientes grandes
• Requer atenção redobrada à comunicação com banco de dados SQL Server

3. Erros mais comuns no dimensionamento

• Usar o mesmo ambiente de homologação como produção
• Ignorar IOPS e latência de disco, priorizando apenas espaço em GB
• Acreditar que “rodou bem para 20 usuários, vai rodar para 50”
• Misturar aplicação e banco no mesmo servidor, sem controle de consumo

Esses erros geram gargalos silenciosos que só aparecem quando a operação já está rodando — e aí, o impacto é sentido na produtividade, nos prazos e até na reputação da empresa.

4. Como fazer um sizing correto

Um dimensionamento técnico bem feito considera:

• Separação clara de camadas:
  
  
  • Aplicação TOTVS
  • Banco de Dados
  • Terminal Server (em caso de RDP)
    
    
• Projeção de crescimento: pense nos próximos 2–3 anos, não apenas no hoje
• Testes de stress controlados: simule acessos simultâneos e cargas reais
• Monitoramento proativo: acompanhe consumo de CPU, memória, I/O e gargalos em tempo real

5. Impactos reais de um sizing mal feito

• Lentidão generalizada
• Quedas no AppServer ou sessões desconectadas
• Processos fiscais não gerando arquivos no tempo previsto
• Painéis de BI com refresh travado
• Backups que ultrapassam o horário de janela
• Equipe perdendo tempo com retrabalho e abertura de chamados

Em empresas com operação contínua, 15 minutos de parada equivalem a uma semana de estresse. E o mais preocupante: sem um sizing bem feito, a TI acaba combatendo sintomas — não a causa.