{"id":49921,"date":"2026-03-10T17:02:43","date_gmt":"2026-03-10T20:02:43","guid":{"rendered":"https:\/\/www.hostinger.com\/pt\/tutoriais\/benchmarks-n8n\/"},"modified":"2026-03-10T17:02:43","modified_gmt":"2026-03-10T20:02:43","slug":"benchmarks-n8n","status":"publish","type":"post","link":"\/pt\/tutoriais\/benchmarks-n8n","title":{"rendered":"Benchmarks n8n: testando o uso real de recursos da ferramenta"},"content":{"rendered":"
Se você está hospedando o n8n por conta própria, provavelmente já se fez a mesma pergunta que eu: quantos recursos do servidor meus workflows do n8n realmente consomem?<\/p>
Afinal, garantir recursos suficientes é essencial para manter um bom desempenho. Ao mesmo tempo, ninguém quer gastar mais do que o necessário em CPU ou memória que acabarão ficando ociosas.<\/p>
Se você pesquisar online, encontrará recomendações diferentes – como usar um processador com um núcleo e 2 GB de RAM. Mas isso levanta algumas dúvidas práticas:<\/p>
\n
Será que eu realmente preciso de tudo isso para um workflow simples?<\/li>\n\n\n\n
Se eu rodar dois workflows, preciso de um servidor duas vezes mais potente?<\/li>\n\n\n\n
O uso de recursos do n8n é previsível em cenários reais?<\/li>\n<\/ul>
Para responder a essas perguntas, realizei uma série de benchmarks n8n em cenários reais, medindo o consumo de CPU, memória RAM e rede de diferentes workflows do n8n em condições variadas.<\/p>
Adiantando as principais conclusões<\/h2>
Antes de entrarmos nos detalhes mais específicos, aqui estão os principais pontos que tirei do meu teste:<\/p>
\n
O consumo de recursos depende do nó<\/strong>. Nós que interagem com fontes externas, como o nó de requisição HTTP, consomem mais recursos de E\/S de rede do que nós que executam tarefas localmente. No entanto, a RAM é o recurso dominante em praticamente todos os nós, internos ou externos.<\/li>\n\n\n\n
A escala é, em certa medida, linear. <\/strong>Executar vários fluxos de trabalho idênticos<\/em> geralmente resulta em uma escalabilidade aproximadamente linear. Ao introduzir variedade de nós, o uso de recursos torna-se muito menos previsível.<\/li>\n\n\n\n
Atrasos não reduzem o pico de uso<\/strong>. Adicionar um intervalo entre as execuções dos nós não afeta o pico de uso. No entanto, isso permite distribuir a alocação de recursos ao longo do tempo, dando espaço para outros fluxos de trabalho.<\/li>\n\n\n\n
Executar fluxos de trabalho em paralelo versus sequencialmente. <\/strong>Não há diferença significativa no pico de utilização de hardware entre a execução de fluxos de trabalho em paralelo e sequencialmente.<\/li>\n\n\n\n
O modo de fila n8n não é nenhum segredo. <\/strong>Habilitar o modo de fila n8n praticamente dobra o uso básico de RAM, mesmo em modo ocioso. Não reduz o consumo máximo em configurações pequenas e só faz sentido em grande escala.<\/li>\n<\/ul>
Metodologia dos benchmarks n8n<\/h2>
Este teste de desempenho se concentrará na utilização máxima de CPU, RAM<\/strong> e E\/S de rede<\/strong> do servidor host. <\/p>
Vale ressaltar que existem outros benchmarks n8n. Por exemplo, a publicação do blog n8n<\/strong> Scalability Benchmark<\/strong> examina como a plataforma lida com um grande volume de solicitações, com foco em métricas como taxa de falhas e tempo de resposta. <\/p>
No entanto, em vez de um benchmark sintético e controlado, concentrei-me na utilização máxima de recursos em cenários práticos de automação no mundo real.<\/p>
\n
Dica de especialista<\/h4>\n
Se você não tem certeza de qual plano VPS da Hostinger melhor se adapta às suas necessidades, comece com o KVM 2 – ele oferece uma base sólida e pode ser atualizado instantaneamente com um único clique à medida que suas necessidades aumentam.<\/p>\n
\n
\n \n <\/div>\n
\n
Minijus Savickas<\/p>\n
Chefe de produto VPS<\/p>\n <\/div>\n <\/div>\n <\/div>\n\n\n\n<\/p>
Vamos explorar a metodologia com mais detalhes, começando por compreender o ambiente de teste. <\/p>
Ambiente de teste e ferramentas utilizadas no benchmark n8n<\/h3>
Segue abaixo a configuração que utilizei para executar os testes de benchmark n8n:<\/p>
\n
Servidor:<\/strong> plano Hostinger VPS KVM 2<\/li>\n\n\n\n
Sistema operacional:<\/strong> Ubuntu Linux 24.04 LTS<\/li>\n\n\n\n
Ferramenta<\/strong> btop<\/strong> para monitoramento, Docker<\/strong> para executar o n8n em um contêiner.<\/li>\n<\/ul>
Escolhi o Hostinger KVM 2 porque oferece recursos suficientes sem ser excessivamente caro. Com dois núcleos de vCPU<\/strong>, 8 GB de RAM<\/strong> e 100 GB de armazenamento SSD NVMe<\/strong>, oferece ampla margem de segurança caso os testes exijam. <\/p>
Quanto ao sistema operacional, escolhi o Ubuntu 24.04 LTS<\/strong> simplesmente por ser estável, fácil de usar e popular. Se você usar uma distribuição mais minimalista, poderá haver pequenas diferenças de desempenho, mas nada que comprometa significativamente a experiência do usuário. <\/p>
Eu implementei o n8n no Docker<\/strong>. Essa é a abordagem de auto-hospedagem recomendada e, com o modelo VPS da Hostinger, instalar o n8n em um contêiner leva apenas alguns cliques. Eu também configurei o modo de fila n8n<\/strong> usando o modelo da Hostinger e suas configurações padrão predefinidas.<\/p>
\n
Pensando no overhead do Docker? 🐳<\/h4>\n
O Docker tem desempenho próximo ao nativo, já que compartilha o kernel do host. Na prática, a sobrecarga é insignificante em comparação com a execução do n8n diretamente no host.<\/p>\n <\/div>\n\n\n\n<\/p>
Para monitoramento, utilizei o btop<\/strong> por ser simples e suficiente para coletar dados para este teste de desempenho. Também fornece um gráfico que simplifica o processo de monitoramento. <\/p>
Cenários de teste e métricas analisadas<\/h3>
Para executar o teste de desempenho, realizei cada um dos seguintes testes em intervalos de 2 segundos durante vários minutos para garantir a consistência dos dados. Em alguns cenários, aumentei o intervalo para evitar os limites de taxa da API.<\/p>
Para cada teste, registrei os valores de pico para:<\/p>
\n
utilização da CPU<\/strong> <\/li>\n\n\n\n
consumo de RAM<\/strong> <\/li>\n\n\n\n
E\/S de rede<\/strong> <\/li>\n<\/ul>
Teste 1: benchmark por node<\/strong><\/p>
Este teste isolou nodes individuais para responder à questão:<\/p>
\n
Quanta CPU, RAM e largura de banda de rede um nó consome?<\/li>\n\n\n\n
Os nós que interagem com serviços externos requerem mais recursos do que aqueles que são executados independentemente dentro do n8n?<\/li>\n\n\n\n
O consumo de recursos aumenta linearmente com o número de nós?<\/li>\n<\/ul>
Importante! <\/strong>Para simplificar, chamarei de nós externos<\/strong> os nós que requerem interação com serviços externos e de nós internos<\/strong> aqueles que são executados independentemente dentro do n8n. <\/p><\/div>\n\n\n\n<\/p>
Teste 2: benchmark de workflow único<\/strong><\/p>
Este teste se concentra em fluxos de trabalho completos:<\/p>
\n
Fluxo de trabalho simples com dois nós internos.<\/li>\n\n\n\n
Fluxo de trabalho complexo com sete nós internos<\/li>\n\n\n\n
Fluxo de trabalho complexo com um total de sete nós, uma combinação de nós internos e externos.<\/li>\n\n\n\n
Efeito da adição de atrasos na execução<\/li>\n<\/ul>
Teste 3: múltiplos workflows na mesma instância<\/strong><\/p>
Este teste analisou: <\/p>
\n
O consumo de CPU, RAM e tráfego aumenta linearmente com o número de fluxos de trabalho idênticos?<\/li>\n\n\n\n
O consumo de recursos é previsível com base no número e tipo de fluxos de trabalho em execução?<\/li>\n\n\n\n
A alternância entre a execução de múltiplos fluxos de trabalho é uma estratégia viável para minimizar picos de consumo de recursos?<\/li>\n<\/ul>
\n <\/div>\n
\n![\"Gráfico](\"\/br\/tutoriais\/wp-content\/uploads\/sites\/53\/2026\/03\/1770910903364-0.png\")