A release 12.1.2410 trouxe mudanças não-óbvias na camada de runtime do Protheus. A maior delas — a substituição parcial do gerenciador de threads — passa despercebida na maioria dos upgrades. Em ambientes com mais de 5k jobs/dia, o efeito aparece como degradação progressiva: nada quebra, mas tudo fica lento.
O que monitorar antes de escalar
Antes de adicionar servidor, capacidade ou banco, é razoável extrair o máximo da configuração atual. Listamos os pontos onde mais vimos performance ser recuperada em projetos HSB nos últimos 12 meses.
1. TopConnect e pool de conexões
O Protheus 12.1.2410 mantém compatibilidade com o TopConnect antigo, mas vem com defaults que assumem 1.000 conexões simultâneas. Em ambiente real com 30+ usuários simultâneos e jobs concorrentes, isso satura rápido. Aumente NumServers para 6-8 e MaxConnections para 4.000 — sem precisar de licença extra.
2. Índices que não aparecem no SX2
A TOTVS cria índices nativos via dicionário de dados (SX2/SX3) que ficam visíveis. Mas customizações antigas podem ter criado índices direto no banco que ninguém documentou. Faça uma varredura nos catálogos do SGBD comparando com o dicionário — em vários projetos achamos 12-15 índices órfãos consumindo I/O sem servir a nenhuma query do Protheus.
3. Parâmetros MV_ esquecidos
MV_TOPATIM, MV_DBCKLOG, MV_BLOQUEI, MV_MAXJOB. Esses quatro parâmetros são deixados em valor default em 90% das instalações que auditamos. Em ambientes de alta concorrência, ajustar MV_BLOQUEI pra 'N' em tabelas específicas (não globalmente) reduz contenção sem comprometer integridade transacional.
4. RPO compilado x AppServer
RPO compilado em desenvolvimento e replicado pra produção sem regerar índices internos do AppServer causa degradação progressiva — o cache fica desalinhado. Sempre regerar RPO direto no servidor de produção, com appserver reiniciado antes do go-live.
Diagnóstico estruturado
Recomendamos o seguinte roteiro antes de qualquer iniciativa de escala vertical ou horizontal:
- 01Coletar 7 dias de logs do AppServer com nível INFO + traces de threads ativas (Console.log + LogProfiler).
- 02Identificar top 20 queries por tempo agregado via TopConsole — geralmente 3 ou 4 queries respondem por 80% do tempo de CPU.
- 03Mapear se essas queries usam índices ou table scan. Frequente: índice existe mas o WHERE foi escrito numa ordem que não aproveita.
- 04Auditar customizações de pontos de entrada (PEs) de alta frequência — A100Cli, M410GRV, MT100GRV. PE custom mal-feito é causa silenciosa de 30-50% dos gargalos.
- 05Validar GC do AdvPL no AppServer — vazamento de memória em rotinas longas é comum em customizações que esquecem dbCloseArea.
Quando escalar de fato faz sentido
Depois de exaurir o diagnóstico acima, escalar vertical (mais CPU/RAM no AppServer) costuma render 30-40% adicional. Escalar horizontal (múltiplos AppServers via balanceador) muda o jogo, mas exige reescrever rotinas que assumem sessão única — coisa que ninguém quer descobrir em produção. Antes de escalar horizontal, isole serviços com mais demanda em AppServer dedicado: SIGAFIS, SIGAFAT e SIGAEST conseguem rodar separados sem riscos.
Performance no Protheus raramente é problema de produto. É quase sempre acúmulo de decisões tomadas sob pressão ao longo de anos. Diagnóstico é mais barato que infraestrutura — e diagnóstico bem feito é o que diferencia uma operação que escala de uma que apaga incêndio.