Performance do Protheus: Guia de Diagnóstico

Aprenda a diagnosticar lentidão no Protheus com linha de base, AppServer, DBAccess, banco, rede, customizações, testes e monitoramento contínuo.

O que significa melhorar a performance do Protheus?

Melhorar a performance do Protheus significa reduzir o tempo e a variabilidade das jornadas importantes sem comprometer integridade, segurança ou capacidade de atualização. O diagnóstico correto não começa aumentando memória ou criando índices: começa identificando onde a espera ocorre, em qual cenário e desde quando.

Uma operação do Protheus envolve camadas interdependentes. SmartClient ou interface web, rede, AppServer, DBAccess, banco de dados, License Server, jobs, integrações e customizações podem participar da mesma transação. Se a causa for atribuída à camada errada, a empresa pode gastar mais e continuar com o mesmo problema.

A própria TOTVS, no material sobre lentidão no Protheus 12, orienta separar problemas generalizados de ocorrências pontuais e avaliar versões, configuração, rede, aplicação e banco. Este guia transforma essa lógica em um roteiro de investigação baseado em evidências.

Classifique a lentidão antes de intervir

“Está lento” não é um diagnóstico. Registre o comportamento em dimensões que permitam comparação:

abrangência: todos os usuários, uma filial, um perfil ou uma estação;
função: sistema inteiro, módulo, rotina, consulta, relatório, job ou integração;
tempo: constante, apenas no pico, depois de uma mudança ou em horários específicos;
dados: qualquer registro ou somente filial, período, produto ou volume determinado;
ambiente: produção, homologação, acesso remoto, nuvem ou rede local;
resultado: demora com conclusão correta, timeout, travamento ou erro;
concorrência: uma execução isolada ou várias operações simultâneas.

A distinção mais importante é entre lentidão generalizada e pontual. Uma rotina lenta para todos pode indicar consulta, regra ou customização específica. Várias rotinas degradadas no mesmo período podem apontar saturação compartilhada, espera no banco, rede, armazenamento ou componente de plataforma. Isso é uma hipótese inicial, não uma conclusão.

Crie uma linha de base verificável

Sem linha de base, qualquer ajuste parece funcionar em um teste curto. Escolha de três a cinco jornadas críticas, como entrar no sistema, consultar um pedido, faturar, contabilizar ou fechar uma rotina. Para cada uma, registre:

início e fim medidos pelo mesmo método;
volume processado e filtros usados;
usuário, filial e ambiente;
quantidade aproximada de sessões concorrentes;
versões dos principais artefatos;
uso de CPU, memória e disco durante o teste;
latência e perda de rede quando aplicável;
mudanças recentes em pacote, configuração, fonte, integração ou infraestrutura;
consultas e esperas relevantes no banco;
horário e identificador para correlacionar logs.

Não reduza a análise a uma média. Compare distribuição, picos e variação. Uma rotina que normalmente leva poucos segundos, mas ocasionalmente demora minutos, exige correlação temporal. Já uma degradação uniforme pode ser investigada por comparação com versão, volume e plano de execução anteriores.

Use dados reais com cuidado. Reproduza em homologação sempre que possível, anonimize informações extraídas para análise e limite a coleta de logs ao período necessário.

Entenda o caminho de uma transação

Um mapa simples evita investigações isoladas. Desenhe a jornada desde a ação do usuário até a confirmação:

dispositivo e cliente;
rede, VPN, proxy ou balanceador;
AppServer responsável;
DBAccess e conexão;
banco de dados;
serviços auxiliares e arquivos;
APIs, mensageria ou sistemas externos;
retorno à interface.

Marque onde existem filas, timeouts, retentativas e logs. Se a tela espera uma integração síncrona, por exemplo, o AppServer pode estar saudável enquanto o usuário aguarda um terceiro. Se um job disputa as mesmas tabelas no fechamento, a causa percebida na aplicação pode ser bloqueio ou contenção no banco.

A Central de Diagnóstico do Protheus reúne informações de artefatos e recursos do ambiente em releases compatíveis. Os pré-requisitos variam; confirme a documentação correspondente à versão instalada antes de habilitar ou interpretar qualquer recurso.

Diagnóstico da performance do Protheus por camada

Cliente e rede

Comece comparando a mesma operação em estações, localidades e caminhos de rede diferentes. Meça latência, perda, estabilidade e variação, não apenas largura de banda contratada. A documentação da TOTVS destaca que a latência afeta o tráfego entre SmartClient e servidor e disponibiliza o recurso SCPing para avaliação no contexto do produto.

Verifique também resolução de nomes, VPN, proxy, inspeção de tráfego e competição com transferências pesadas. Um teste local no mesmo segmento do servidor ajuda a separar aplicação de caminho de acesso, mas não representa a experiência de uma filial. Compare os dois.

Evite definir um número universal como “latência aceitável”. A sensibilidade depende da quantidade de interações da rotina, do desenho da tela e da arquitetura. O objetivo é mostrar correlação entre a degradação e o caminho medido.

AppServer

No AppServer, correlacione o período lento com CPU, memória, threads, filas, reinícios, coleta de logs e distribuição de responsabilidades. Observe se usuários, jobs e serviços de integração disputam a mesma capacidade.

A orientação oficial sobre lentidão recomenda avaliar a coesão dos AppServers e a separação de responsabilidades para usuários, jobs e serviços. Isso não significa multiplicar instâncias sem cálculo. Primeiro determine qual carga causa saturação, qual recurso limita a execução e como a topologia reagirá a falha e manutenção.

Confira ainda a compatibilidade entre AppServer, DBAccess, bibliotecas e demais componentes. Atualizar por impulso em produção mistura diagnóstico com mudança e pode introduzir outra variável. Valide a matriz aplicável, reproduza em homologação e use o processo descrito no artigo sobre atualização do Protheus.

DBAccess e banco de dados

A investigação deve conectar o sintoma da aplicação às sessões e consultas do banco. Procure:

consultas com maior tempo ou frequência no período;
bloqueios, esperas e concorrência;
planos de execução incompatíveis com o volume atual;
estatísticas desatualizadas;
índices ausentes, redundantes ou pouco seletivos;
crescimento de dados e arquivos;
pressão de CPU, memória, I/O e conexões;
rotinas de manutenção ou backup concorrendo com o uso;
falhas ou saturação entre AppServer, DBAccess e banco.

Não crie um índice apenas porque um filtro está lento. Colete consulta, parâmetros, plano, cardinalidade e padrão de escrita. Um índice pode acelerar leitura e aumentar custo de inserção, atualização, armazenamento e manutenção. Da mesma forma, reconstruir todos os índices durante um incidente pode gerar carga adicional e esconder a causa.

O guia oficial de baixa performance no Protheus reforça a participação do DBA na análise de índices, estatísticas, consultas e manutenção. Qualquer intervenção deve seguir os procedimentos do banco utilizado, possuir janela, backup validado, critérios de sucesso e reversão.

Customizações e regras específicas

Quando apenas uma rotina ou etapa apresenta lentidão, compare o comportamento padrão e customizado em ambiente controlado. Identifique pontos de entrada, fontes, relatórios, gatilhos, consultas e chamadas externas executados naquela jornada.

O LogProfiler da Central de Diagnóstico registra tempos de execução de programas AdvPL e ajuda a localizar trechos custosos. Use-o com escopo e duração definidos: profiling e traces podem aumentar volume de logs e alterar o comportamento observado.

Antes de otimizar código, descubra se a demora está em processamento, acesso ao banco, repetição de chamadas ou dependência externa. Uma consulta dentro de um laço, por exemplo, pede correção diferente de um serviço externo instável. Documente o cenário e teste regressão funcional; velocidade não compensa um cálculo incorreto.

Para revisar desenho, versionamento e testes das extensões, consulte o guia de customização no Protheus.

Jobs, fechamentos e integrações

Mapeie schedules, importações, relatórios pesados, backups e integrações por horário. Procure sobreposição com picos de usuários ou fechamentos. Uma tarefa individualmente aceitável pode degradar o ambiente quando coincide com outras cargas.

Em integrações, registre tempo do Protheus separado do tempo de rede e do sistema externo. Defina timeout, idempotência e fila quando o processo permitir. Retentativas sem limite podem amplificar uma indisponibilidade; processamento síncrono desnecessário pode manter sessões ocupadas.

Se a jornada cruza vários sistemas, acompanhe um identificador de negócio, como pedido ou nota, em todos os componentes. Isso aproxima o diagnóstico técnico do impacto operacional.

Trabalhe com hipóteses e testes controlados

Organize a investigação em uma tabela:

Hipótese	Evidência esperada	Teste	Risco	Resultado
caminho de rede instável	variação por localidade	comparar execução local e remota	baixo	confirmar ou descartar
consulta degradada	espera e plano anormal	analisar sessão e plano no período	baixo	identificar objeto
job concorrente	picos nos mesmos horários	reproduzir sem sobreposição em teste	médio	medir diferença
customização custosa	tempo concentrado no fonte	profiler em cenário controlado	médio	localizar trecho
capacidade saturada	fila e recurso no limite	teste de carga representativo	médio	determinar limite

Altere uma variável por vez. Defina antes o que confirmará ou rejeitará a hipótese. Registre configuração anterior, nova configuração, responsável e modo de retorno. Se o teste não reproduzir volume, dados, concorrência e integrações, declare essa limitação.

Não aplique parâmetros encontrados em fóruns ou em outro ambiente sem conferir documentação e versão. Nomes de chaves podem permanecer enquanto comportamento, valor recomendado ou dependência muda.

Use monitoramento para evitar diagnósticos tardios

Depois da correção, transforme as evidências úteis em acompanhamento contínuo. O TOTVS Discovery documenta monitoramento de componentes como AppServer, DBAccess, License Server e banco de dados em ambientes compatíveis. Ferramentas nativas ou externas devem ser escolhidas conforme release, arquitetura e capacidade de operação da equipe.

Um painel útil combina tecnologia e jornada:

tempo das rotinas críticas por período;
taxa de erro e timeout;
sessões e concorrência;
fila e utilização dos AppServers;
CPU, memória e armazenamento;
conexões, esperas e bloqueios no banco;
duração e falhas de jobs;
tempo e erro de integrações;
versão e mudanças implantadas;
volume de dados processado.

Defina alertas por impacto e tendência. CPU alta durante um processamento previsto não é necessariamente incidente; uma fila crescente com faturamento parado é acionável. Todo alerta precisa de responsável, contexto e runbook.

O artigo sobre observabilidade de sistemas aprofunda métricas, logs, traces, SLOs e desenho de alertas.

Erros comuns no diagnóstico

Os erros que mais prolongam a lentidão são:

reiniciar serviços antes de coletar evidências;
culpar o banco ou a rede sem correlação;
comparar testes com volumes e horários diferentes;
mudar vários parâmetros simultaneamente;
executar profiler indefinidamente;
criar índices sem analisar plano e custo de escrita;
aumentar hardware sem identificar saturação;
testar só a tela e ignorar jobs ou integrações;
tratar atualização como correção automática;
fazer manutenção em produção sem janela e retorno;
encerrar o incidente sem registrar causa e prevenção.

Reiniciar pode restaurar temporariamente o serviço e ainda ser necessário. Nesse caso, preserve o que for possível antes da ação: horário, sessões, métricas, logs, processos e mudanças recentes. Depois, acompanhe se o padrão reaparece.

Checklist para investigar lentidão no Protheus

Antes do teste

definir rotina, usuário, filial, volume e horário;
registrar comportamento esperado e observado;
identificar última ocorrência normal;
levantar mudanças recentes;
mapear componentes e dependências;
preparar homologação e critérios de segurança.

Durante a reprodução

usar o mesmo roteiro e a mesma forma de medição;
correlacionar relógios e identificadores;
coletar cliente, rede, AppServer, DBAccess e banco;
observar jobs e integrações concorrentes;
limitar logs e traces ao necessário;
alterar uma variável por vez.

Antes da correção

confirmar a hipótese com evidência;
avaliar compatibilidade com a release;
medir impacto funcional, técnico e de segurança;
validar com DBA e responsáveis pelo módulo;
documentar implantação e reversão;
testar carga e regressão.

Após a mudança

repetir o cenário de referência;
comparar tempo, variação e consumo;
acompanhar pico e fechamento;
verificar efeitos colaterais;
atualizar runbook, linha de base e monitoramento;
registrar causa, decisão e ação preventiva.

Como estruturar a melhoria contínua

A performance do Protheus não deve depender de uma força-tarefa a cada fechamento. Mantenha inventário de componentes, histórico de mudanças, jornadas de referência, capacidade, manutenção do banco e revisão das customizações. Reavalie a linha de base quando volume, release, topologia ou processo de negócio mudar.

A consultoria TOTVS Protheus da Mattos Tech Solutions pode apoiar o diagnóstico entre aplicação, banco, infraestrutura e integrações. Quando a investigação exigir revisão mais ampla de capacidade, riscos e operação, conheça também a consultoria de TI.

Se sua empresa precisa localizar a causa da lentidão e transformar evidências em um plano seguro de correção, fale com a Mattos Tech Solutions.