A pergunta que chega é quase sempre a mesma: quanto de servidor uma base de tantos mil contatos exige?

E, como em qualquer dimensionamento, o número de contatos é justamente a informação menos útil. Duas instâncias com trinta mil contatos podem exigir servidores completamente diferentes — porque o que consome recursos no Mautic não é guardar contatos, e sim processá-los.

Uma base de trinta mil contatos com três segmentos simples e uma campanha ativa é irrelevante em termos de carga. A mesma base com quarenta segmentos que cruzam múltiplos critérios, quinze campanhas rodando e disparos semanais para toda a lista é outra história.

Este guia mostra o que realmente pesa, o que medir na sua instância e como converter isso em configuração.

Onde o Mautic gasta recursos

Quatro frentes, em ordem de impacto na maioria das instalações:

1. Recálculo de segmentos

É o maior consumidor e o menos óbvio.

Cada segmento é uma regra que precisa ser aplicada aos contatos para determinar quem entra e quem sai. Esse recálculo roda por tarefa agendada, e o custo depende de dois fatores multiplicados: quantos segmentos existem e quão complexa é a regra de cada um.

Segmentos que cruzam vários critérios — comportamento, campo personalizado, data de interação, pertencimento a outro segmento — geram consultas caras ao banco. Quarenta segmentos assim recalculando sobre uma base grande é o que mais trava instâncias de Mautic.

2. Processamento de campanhas

Cada campanha ativa é avaliada a cada ciclo, verificando quais contatos avançaram de etapa e quais ações precisam ser executadas.

O custo cresce com o número de campanhas ativas, com a quantidade de etapas em cada uma e com o número de contatos em trânsito dentro delas. Campanhas antigas que ninguém desativou continuam sendo avaliadas — e é comum encontrar instâncias processando campanhas que ninguém usa há meses.

3. Volume de envio no pico

O momento de maior carga é o disparo para uma base grande: o Mautic precisa montar cada mensagem, processar a personalização, registrar o envio e entregar ao serviço de envio.

Diferente das duas frentes anteriores, esta é concentrada: acontece em janelas específicas e some depois.

4. Registro de atividade

Cada abertura, clique, visita de página rastreada e mudança de estágio gera registro. Em bases ativas, essa tabela cresce mais rápido que qualquer outra — e é o principal fator de degradação ao longo do tempo.

O que medir

Seis números, todos obtidos na instância atual ou em um ambiente de teste com dados representativos:

1. Quantidade de segmentos ativos e, para cada um, quantos critérios a regra combina.
2. Tempo de execução do recálculo de segmentos — quanto leva o comando completo.
3. Campanhas ativas e número de contatos em trânsito em cada uma.
4. Volume do maior disparo já realizado, e a frequência com que ele se repete.
5. Tamanho do banco de dados e a taxa de crescimento semanal, com atenção às tabelas de atividade.
6. Consumo de memória e processamento durante a janela de execução das tarefas agendadas — não a média do dia.

O item 2 é o mais revelador de todos. Se o recálculo de segmentos leva mais tempo do que o intervalo entre execuções, as tarefas começam a se sobrepor — e o servidor entra em um estado de saturação permanente, com execuções acumulando enquanto novas são iniciadas.

Esse é o modo de falha mais comum em instâncias de Mautic que cresceram, e ele explica o sintoma clássico: a plataforma que funcionava bem e foi ficando progressivamente mais lenta sem que nada aparente tivesse mudado.

O padrão de carga é diferente de um site

Uma característica que muda o dimensionamento e costuma passar despercebida.

Um site tem carga distribuída ao longo do dia, seguindo o comportamento dos visitantes. O Mautic tem carga concentrada nas janelas de execução das tarefas agendadas — que é quando o trabalho pesado acontece.

Isso tem duas consequências práticas:

A média de consumo engana. Um servidor com média confortável pode estar saturando completamente durante as janelas de processamento. Medir a média é medir a coisa errada.

O escalonamento das tarefas importa. Se todos os comandos disparam no mesmo minuto, eles competem entre si e o pico é muito maior do que precisaria ser. Escaloná-los reduz a exigência de recursos sem custo nenhum.

Esse ponto se conecta ao que já tratamos sobre a ordem e a configuração das tarefas no artigo sobre servidor para Mautic.

Por que não publicamos uma tabela por número de contatos

Essa tabela circula, e é a origem de dimensionamentos errados nos dois sentidos.

Uma base de cem mil contatos usada como arquivo — poucos segmentos, disparos esporádicos, nenhuma campanha complexa — exige menos que uma base de vinte mil com segmentação elaborada e automação contínua.

O que substitui a tabela é o método: dimensione a memória pelo pico durante a janela de processamento, considerando o comando mais pesado; reserve a parte do banco separadamente; e verifique se o tempo de recálculo cabe no intervalo entre execuções. Esse último critério é o que determina se a configuração é suficiente.

O banco de dados: o gargalo mais comum

Em instâncias de Mautic que rodam há algum tempo, o banco costuma ser a restrição real.

Duas razões:

As consultas de segmentação são pesadas por natureza. Cruzar critérios sobre uma tabela de contatos grande, repetidamente, é trabalho intenso de banco — e nenhuma quantidade de memória na aplicação compensa um banco saturado.

As tabelas de atividade crescem sem parar. Registros de abertura, clique, visita e mudança de estágio acumulam continuamente. Sem política de retenção, elas se tornam as maiores do banco e degradam todas as consultas que as tocam.

O que fazer:

• Configurar a limpeza de dados antigos, que o Mautic oferece por comando próprio. Deve fazer parte da instalação, não da manutenção futura.
• Revisar segmentos periodicamente, desativando os que não são mais usados. Cada segmento ativo é custo permanente.
• Desativar campanhas encerradas, pelo mesmo motivo.
• Reservar memória adequada para o banco, que é onde ela rende mais nesta aplicação.
• Considerar separar o banco em outro servidor quando a base for grande, dando a ele recursos dedicados.

O segundo item merece nota: é comum encontrar instâncias com dezenas de segmentos criados para campanhas antigas, todos recalculando indefinidamente. Uma limpeza de segmentos costuma render mais que um upgrade de servidor.

Sinais de que a configuração não comporta

• O recálculo de segmentos não termina antes da próxima execução começar.
• A interface fica lenta durante as janelas de processamento e normaliza fora delas.
• Disparos demoram muito para sair da fila.
• Contatos entram em campanhas com atraso perceptível em relação ao evento que deveria acioná-los.
• Erros de memória durante execuções de comandos.
• O banco cresce e a plataforma fica progressivamente mais lenta, sem mudança de uso.

O quarto sinal é o mais relevante do ponto de vista de negócio: uma automação que deveria reagir em minutos e reage em horas perde boa parte do efeito. Em fluxos de recuperação de carrinho ou resposta a formulário, o atraso é a diferença entre converter e não converter.

Antes de aumentar recursos

Como em qualquer dimensionamento, vale eliminar as hipóteses baratas primeiro:

1. Desative segmentos e campanhas que não são usados. É a intervenção de maior impacto e custo zero.
2. Simplifique as regras de segmentação mais pesadas, quando o mesmo resultado for alcançável com menos critérios cruzados.
3. Configure a retenção de dados de atividade, se ainda não estiver ativa.
4. Escalone as tarefas agendadas em vez de dispará-las simultaneamente.
5. Ajuste o tamanho dos lotes de processamento, que os comandos permitem configurar — lotes menores consomem menos memória por execução.
6. Verifique se o envio está sendo feito por serviço adequado, e não pelo próprio servidor da aplicação, o que consome recursos e prejudica a entrega.

Feitas essas seis, meça de novo. Em instâncias que cresceram sem manutenção, elas costumam resolver o problema sem custo adicional.

Quando a restrição é real

Se depois da limpeza e dos ajustes o recálculo continua não cabendo na janela, ou a memória satura durante o processamento, a restrição é de capacidade.

O que priorizar, em ordem:

• Memória, que é onde o banco e o processamento de segmentos mais se beneficiam.
• Processamento, relevante para consultas complexas e para volume de envio.
• Disco, considerando o crescimento das tabelas de atividade e o histórico.
• Separação do banco, para bases grandes.

E vale a ressalva de sempre: capacidade adicional não corrige segmentação mal construída nem compensa a ausência de retenção. Ela apenas eleva o teto — o problema volta com a base um pouco maior.

Conclusão

Dimensionar um servidor para Mautic não parte do número de contatos, e sim da estrutura da operação: quantos segmentos existem e quão complexos são, quantas campanhas estão ativas, qual o volume de envio no pico e quanto a tabela de atividade cresce.

O critério que resolve a maior parte das dúvidas é objetivo: o recálculo de segmentos precisa terminar antes da próxima execução começar. Se não termina, a configuração é insuficiente — ou a segmentação está mais complexa do que precisa.

E, antes de contratar mais recursos, vale a limpeza que costuma render mais que um upgrade: desativar segmentos e campanhas que ninguém usa. Conheça o Cloud Server para Mautic da TBF Host e avalie a configuração a partir dos números da sua operação.

Perguntas frequentes

Quanto de servidor o Mautic precisa para minha base de contatos?

O número de contatos é a informação menos útil para dimensionar. O que consome recursos é o processamento: quantos segmentos existem e quão complexas são suas regras, quantas campanhas estão ativas, qual o volume de envio no pico e quanto a tabela de atividade cresce. Duas bases do mesmo tamanho podem exigir servidores muito diferentes.

O que mais consome recursos no Mautic?

O recálculo de segmentos é o maior consumidor na maioria das instalações, porque cada segmento é uma regra aplicada repetidamente aos contatos. Em seguida vêm o processamento de campanhas ativas, o volume de envio nas janelas de disparo e o crescimento das tabelas de registro de atividade.

Por que meu Mautic ficou lento com o tempo?

Duas causas se somam: o acúmulo de segmentos e campanhas que ninguém desativou, todos continuando a ser processados, e o crescimento das tabelas de atividade sem política de retenção. Ambos degradam as consultas ao banco, que é o gargalo mais comum em instâncias que rodam há algum tempo.

Como saber se meu servidor comporta a operação?

O critério mais objetivo é verificar se o recálculo de segmentos termina antes da próxima execução começar. Quando não termina, as tarefas se sobrepõem e o servidor entra em saturação permanente — que é o modo de falha mais comum em instâncias de Mautic que cresceram.

Por que a média de consumo do servidor engana no Mautic?

Porque a carga é concentrada nas janelas de execução das tarefas agendadas, e não distribuída ao longo do dia como em um site. Um servidor com média confortável pode estar saturando completamente durante o processamento. É preciso medir o pico durante essas janelas.

O que fazer antes de contratar mais recursos?

Desativar segmentos e campanhas não utilizados, simplificar regras de segmentação muito complexas, configurar a retenção de dados de atividade, escalonar as tarefas agendadas em vez de dispará-las juntas, ajustar o tamanho dos lotes de processamento e confirmar que o envio usa um serviço adequado.

Vale a pena separar o banco de dados do Mautic em outro servidor?

Para bases grandes, sim. As consultas de segmentação são pesadas por natureza, e o banco costuma ser a restrição real em instâncias com muitos segmentos e histórico extenso. Separá-lo dá a ele memória e processamento dedicados, o que rende mais que aumentar os recursos de um servidor compartilhado entre aplicação e banco.

Contatos estão entrando em campanhas com atraso. É problema de servidor?

Pode ser. Quando as tarefas agendadas não terminam no intervalo previsto, tudo atrasa — inclusive o avanço de contatos nas campanhas. É o sinal mais relevante do ponto de vista de negócio, porque uma automação que deveria reagir em minutos e reage em horas perde boa parte do efeito.