A pergunta mais recorrente antes de qualquer renovação de infraestrutura para o TOTVS Protheus é direta: “qual servidor eu preciso?”. A resposta correta depende de oito variáveis que a maioria das propostas comerciais não pergunta — e que determinam se o ambiente vai funcionar bem ou vai travar no fechamento fiscal.
Este guia apresenta a Matriz de Sizing da Adentro para o TOTVS Protheus: a metodologia que usamos para dimensionar ambientes antes de qualquer implantação, com perfis de referência, premissas explícitas e os erros mais comuns que comprometem o desempenho mesmo em servidores novos.
Neste artigo
- Por que o sizing do Protheus exige mais atenção
- As 8 variáveis que determinam o servidor
- Arquitetura em camadas: o que dimensionar em cada componente
- Perfis de referência com premissas explícitas
- Storage e IOPS: o gargalo mais comum
- Seis erros de sizing que comprometem o desempenho
- Quando revisar o dimensionamento
- Perguntas frequentes
Por que o sizing do TOTVS Protheus exige mais atenção do que outros sistemas
O TOTVS Protheus roda em uma arquitetura em três camadas — AppServer, DBAccess e banco de dados (SQL Server) — que distribui o processamento de forma diferente de aplicações web modernas. Cada camada tem seus próprios gargalos, e subdimensionar qualquer uma delas é suficiente para comprometer o desempenho do sistema inteiro, mesmo que as outras estejam corretas.
O Protheus é especialmente sensível a dois fatores que muitos times de TI subestimam: IOPS de storage e latência de rede entre o AppServer e o banco de dados. Um servidor com muita CPU e RAM pode ainda assim ser lento se o storage não entregar IOPS suficiente. Essa é a origem da maioria dos chamados de lentidão que recebemos de empresas que acabaram de comprar hardware novo.
Diferente de aplicações web com muitos usuários leves, o Protheus tem operações pesadas por sessão — especialmente em módulos de manufatura, fiscal e folha de pagamento. Um usuário rodando um fechamento de custo ou emitindo NF-e em lote pode consumir mais recursos do que dez usuários em operações simples de consulta.
As 8 variáveis que determinam o servidor do Protheus
Estas são as variáveis que levantamos em todo sizing de ambiente Protheus. Cada uma afeta a infraestrutura de forma distinta — ignorar qualquer uma delas compromete a precisão do dimensionamento.
| Variável | Dado a coletar | Efeito na infraestrutura | Risco se não avaliado |
|---|---|---|---|
| Usuários simultâneos | Pico de usuários conectados ao AppServer ao mesmo tempo | CPU e RAM do AppServer (cada sessão ativa consome memória) | AppServer saturado → travamentos e timeout de sessão |
| Módulos ativos | Lista de módulos em produção (Financeiro, Fiscal, Manufatura, Folha…) | RAM e IOPS — módulos fiscais e de manufatura são os mais pesados | Subdimensionamento ao ativar módulo após a implantação |
| Volume transacional | NFs/dia, pedidos/dia, lançamentos contábeis/dia, movimentos de estoque | IOPS do storage e memória do SQL Server (buffer pool) | Storage gargalo → lentidão generalizada no horário de pico |
| Jobs batch | Quais rotinas batch rodam, em quais horários e por quanto tempo | Pico de CPU e IOPS — pode dobrar o consumo durante execução | Batch concorrendo com operação normal → lentidão em fechamento fiscal |
| Crescimento do banco | Volume atual em GB e crescimento anual estimado | Capacidade total de storage e tempo de backup/restore | Storage cheio → Protheus indisponível; restore demorado em incidentes |
| Customizações ADVPL | Volume e complexidade das customizações desenvolvidas | CPU adicional por rotinas mal otimizadas ou consultas pesadas | Ambiente superdimensionado para cobrir ineficiência de código |
| Integrações externas | APIs, EDI, transportadoras, e-commerce, SEFAZ | CPU, rede e IOPS adicionais — especialmente em integrações síncronas | Gargalo na integração confundido com problema de servidor |
| Política de retenção | Por quanto tempo manter dados online, near-line e em arquivo | Storage de longo prazo e estratégia de tiering | Dado crítico inacessível por falta de espaço ou política mal definida |
Arquitetura em camadas: o que dimensionar em cada componente
O TOTVS Protheus distribui o processamento em componentes distintos. Entender o papel de cada um é essencial para dimensionar corretamente — e para identificar a camada certa quando há lentidão.
AppServer — processamento das rotinas
O AppServer executa as rotinas do Protheus e gerencia as sessões dos usuários. Consome CPU e RAM proporcionalmente ao número de sessões ativas e à complexidade das rotinas em execução. É possível ter mais de um AppServer (balanceamento de carga), mas cada instância precisa ser dimensionada individualmente com base no pico de usuários simultâneos que vai atender.
DBAccess — o conector
O DBAccess é o middleware que traduz as chamadas do AppServer para o banco de dados. Deve ter baixa latência com o AppServer — preferencialmente no mesmo servidor ou no mesmo segmento de rede. Alta latência entre DBAccess e banco é uma das causas mais invisíveis de lentidão no Protheus.
SQL Server — o banco de dados
O SQL Server é o componente mais sensível ao sizing. Dois fatores são críticos:
- RAM (buffer pool): o SQL Server carrega as páginas de dados em memória para servir as consultas. RAM insuficiente força leituras constantes no disco — e IOPS alto não compensa RAM baixa nesse cenário.
- IOPS: operações de escrita (NFs, lançamentos, movimentos de estoque) precisam de IOPS consistente e baixa latência de I/O. Storage inadequado é o principal gargalo de desempenho no Protheus.
Storage — a camada que mais impacta a percepção do usuário
O storage do Protheus precisa entregar IOPS suficiente para o banco de dados e para os arquivos de log e temporários. Storage HDD ou SATA de geração anterior é incompatível com ambientes Protheus em produção com mais de 20 usuários simultâneos sem risco de lentidão. Storage All-Flash entrega latência de I/O abaixo de 1ms de forma consistente.
Latência de rede entre AppServer e SQL Server
Em ambientes em nuvem, a comunicação entre AppServer e banco deve ocorrer na rede privada interna — não pela internet pública. Latência acima de 2ms nesse trecho já impacta a percepção de desempenho dos usuários.
Perfis de referência com premissas explícitas
Leia antes de usar esta tabela
Os perfis abaixo são pontos de partida, não especificações definitivas. Módulos de Manufatura, Fiscal e Folha aumentam os requisitos. Customizações ADVPL extensas podem elevar o consumo de CPU em 50% ou mais. Um sizing preciso exige o levantamento das 8 variáveis da matriz acima.
| Perfil | Usuários simultâneos | vCPUs AppServer | RAM AppServer | RAM SQL Server | IOPS mínimo¹ | Premissa |
|---|---|---|---|---|---|---|
| Pequeno | Até 20 | 4–8 | 16 GB | 16–32 GB | 3.000+ | Módulos básicos (Financeiro + Estoque). Sem manufatura. Banco < 100 GB. |
| Médio | 20–60 | 8–16 | 32–64 GB | 32–64 GB | 8.000+ | Inclui Fiscal e/ou Folha. Jobs batch noturnos. Banco 100–500 GB. |
| Grande | 60–150 | 16–32 | 64–128 GB | 64–128 GB | 15.000+ | Manufatura ativa. Alto volume de NFs e movimentos. Banco 500 GB–2 TB. |
| Crítico / 24×7 | 150+ ou operação contínua | 32+ | 128+ GB | 128+ GB | 25.000+ | Alta disponibilidade obrigatória. AppServer redundante. Storage All-Flash dedicado. |
¹ IOPS medido no storage do banco de dados em operação mista (leitura e escrita). Ambientes com All-Flash NVMe atendem qualquer perfil acima com folga.
Storage e IOPS: o gargalo mais comum no Protheus
Se o Protheus está lento em um servidor com boa CPU e RAM, o storage é o primeiro lugar para investigar. O banco de dados realiza operações de leitura e escrita com alta frequência — especialmente em operações fiscais, cálculo de custo e fechamento de folha. Storage com baixo IOPS não consegue atender essas demandas, e o resultado é lentidão que aumenta proporcionalmente ao volume de usuários e transações.
O diagnóstico é direto: monitore o tempo de resposta de I/O do storage durante o horário de pico. Se a latência de I/O do banco estiver consistentemente acima de 5ms, o storage é o gargalo — independentemente de quantos cores ou GB de RAM o servidor tenha.
Pure Storage All-Flash nos ambientes Adentro
Todos os ambientes gerenciados da Adentro utilizam Pure Storage All-Flash, que entrega IOPS consistente com latência abaixo de 1ms. A tecnologia de compressão e deduplicação reduz o armazenamento efetivo do banco do Protheus em até 5:1 na média. Snapshots de volume são incluídos como ponto de recuperação adicional, sem impacto de desempenho durante a operação.
Seis erros de sizing que comprometem o desempenho
Estes são os erros mais comuns que identificamos ao analisar ambientes Protheus com problemas de desempenho:
- Dimensionar pelo total de usuários cadastrados, não pelo simultâneo. O AppServer consome recursos por sessão ativa. Uma empresa com 200 usuários cadastrados pode ter pico de 40 simultâneos — são esses 40 que determinam o dimensionamento, não os 200.
- Ignorar os jobs batch no cálculo de pico. Fechamento fiscal, cálculo de custo e integração noturna podem dobrar o consumo de CPU e IOPS. Se o batch roda junto com a operação normal, o sizing precisa contemplar os dois picos ao mesmo tempo.
- Compensar storage inadequado com mais CPU e RAM. CPU e RAM não resolvem gargalo de IOPS. Comprar um servidor mais potente sem trocar o storage é desperdício de investimento.
- Não projetar o crescimento do banco de dados. O banco do Protheus cresce substancialmente com o tempo em ambientes com alto volume de NFs e movimentos. Storage subdimensionado hoje causa problemas em 12 a 18 meses.
- Subdimensionar a RAM do SQL Server. O SQL Server precisa manter o working set do banco em memória. RAM insuficiente força leituras constantes no disco — mesmo com All-Flash, isso impacta o desempenho.
- Tratar customizações mal otimizadas como problema de infraestrutura. Rotinas ADVPL com consultas sem índice ou loops desnecessários consomem CPU de forma desproporcional. Aumentar a infra não resolve ineficiência de código — apenas mascara o problema.
Quando revisar o dimensionamento do servidor
O sizing não é estático. Revise o dimensionamento do ambiente Protheus sempre que ocorrer um destes eventos:
- Ativação de novos módulos — especialmente Fiscal, Manufatura/PCP ou Folha de Pagamento
- Aumento superior a 20% no número de usuários simultâneos
- Integração de sistemas externos (EDI, e-commerce, transportadoras, SEFAZ)
- Jobs batch com duração crescente — mais que o dobro do tempo habitual é sinal de alerta
- Atualização de versão do Protheus ou do SQL Server
- Crescimento do banco acima de 30% em relação ao volume no sizing original
Precisa dimensionar um servidor para o TOTVS Protheus?
Use o ACS Cloud Designer para montar o ambiente ou entre em contato para um levantamento técnico sem compromisso.
Perguntas frequentes
Quantos usuários simultâneos um AppServer com 64 GB de RAM suporta no Protheus?
Depende dos módulos e do perfil de uso. Em módulos leves (consulta, entrada de pedidos), 64 GB de RAM no AppServer pode suportar 60 a 80 usuários simultâneos. Em módulos pesados (manufatura, fiscal com alto volume de escrita) ou com customizações extensas, esse número pode ser significativamente menor. A RAM é um dos parâmetros de sizing — não o único.
O TOTVS Protheus pode rodar em servidor virtualizado?
Sim. O Protheus roda em ambientes virtualizados (VMware, Hyper-V) e em nuvem privada. A virtualização não impacta o desempenho quando o storage subjacente tem IOPS adequado e os recursos de CPU e RAM são alocados sem overprovisioning excessivo. Todos os ambientes Protheus da Adentro rodam em nuvem privada virtualizada com Pure Storage.
Qual versão do SQL Server é compatível com o TOTVS Protheus?
A compatibilidade depende da versão do Protheus em uso. Consulte sempre as notas de release oficiais da TOTVS para a versão que você opera — as recomendações mudam a cada release e não devem ser tratadas como fixas.
Como o storage All-Flash melhora o desempenho do Protheus na prática?
O All-Flash entrega latência de I/O abaixo de 1ms de forma consistente — contra 5 a 20ms de storages baseados em disco mecânico. Para o Protheus, isso significa que operações de escrita em NF-e, lançamentos e movimentos de estoque completam muito mais rápido, e o SQL Server consegue servir as consultas com menos espera de I/O. O impacto é perceptível imediatamente após a migração.
Por que o Protheus está lento mesmo com servidor novo?
As causas mais comuns em ambientes com hardware novo são: storage com IOPS insuficiente (mesmo sendo SSD de entrada), RAM insuficiente para o buffer pool do SQL Server, customizações ADVPL mal otimizadas, ou jobs batch concorrendo com a operação normal. Veja o artigo sobre TOTVS Protheus lento: causas e diagnóstico para um roteiro de investigação por camadas.
É possível separar AppServer e SQL Server em servidores físicos diferentes?
Sim, e em ambientes maiores é recomendado. A separação permite dimensionar cada camada de forma independente. O requisito crítico é que a latência de rede entre AppServer/DBAccess e SQL Server seja baixa — abaixo de 2ms. Em nuvem privada, isso é garantido pela rede interna do datacenter.
Quanto storage preciso para o banco do Protheus?
O ponto de partida é o volume atual do banco mais a projeção de crescimento para 24 a 36 meses, com margem de segurança de 30%. Ambientes com All-Flash e compressão/deduplicação reduzem o consumo físico em até 5:1 — um banco de 2 TB pode ocupar 400 GB de storage físico. Considere também espaço para logs de transação, tempdb e backups locais.
O sizing muda quando novos módulos são ativados?
Sim. Módulos de Manufatura/PCP, Fiscal e Folha de Pagamento têm impacto relevante em CPU, RAM e IOPS. O erro mais comum é fazer o sizing com os módulos do go-live e não revisá-lo ao ativar módulos adicionais. Faça a revisão antes de colocar cada novo módulo em produção.
