Já se perguntou o quão difícil você pode empurrar o N8N antes de começar a agitar a bandeira branca? Empurramos o N8N para os limites, com resultados impressionantes.
Quando você está executando fluxos de trabalho da missão crítica, você precisa conhecer seus limites. Por isso, colocamos recentemente implantações diferentes do N8N em seus passos – simulando o tráfego intenso e maximizando os recursos para ver quais configurações são lançadas no topo.
Esteja você executando uma agitação lateral ou gerenciando a engenharia de uma organização multinacional, o teste de estresse ajuda bastante a prevenir tempo de inatividade, gargalos e promessas quebradas. Este blog de referência e vídeo Vou mostrar exatamente o quão longe o N8N pode ir e para onde começa a desmoronar!
Um treino para o seu fluxo de trabalho
Estressamos o N8N testado em dois tipos de instância da AWS – C5.Large e C5.4xlarge – usando o single do N8N e Fila Modos (arquitetura com base em fila multi-thread). Utilizamos o K6 para teste de carga, Beszel para monitoramento de recursos ao vivo e os fluxos de trabalho de benchmarking do N8N para acionar automaticamente cada cenário de teste de estresse.
Esse fluxo de trabalho usou uma planilha para iterar através de diferentes níveis de usuário virtual (VUS), executando cada teste e registrando os resultados à medida que avançar. Depois que os dados foram registrados, transformamos -os em um gráfico que revelou os principais indicadores de desempenho. Além disso, em tempo real, podíamos ver o desempenho do sistema sob cargas variadas-a rapidez com que ele respondeu, quão confiável ele executou e onde começou a rachar.
Veja como configuramos:
O C5.LARGE AWS instância compreendida:
- 1 vcpus
- 2 tópicos
- 4 GB RAM
- 10 Gbps de largura de banda
Quando escalamos para o C5.4xlargeAdicionamos 16 VCPUs + 32 GB de RAM.
Executamos três cenários críticos de benchmarking:
- Single webhook: um fluxo acionado repetidamente
- Multi webhook: 10 fluxos de trabalho acionados em paralelo
- Dados binários: Grandes uploads de arquivo e processamento
Cada teste escalou de 3 a 200 usuários virtuais para medir:
- Pedidos por segundo
- Tempo médio de resposta
- Taxa de falha sob carga
Se você deseja configurar seus próprios testes de estresse, incluímos todas as ferramentas necessárias para começar no final deste blog, incluindo o N8N Scripts de referência.
Single webhook
Começamos pequenos com um único webhook. Isso imitou o envio de uma solicitação de gancho da web a um servidor N8N e enviando uma resposta de volta que recebemos essa chamada de webhook. Este era apenas um fluxo de trabalho e um ponto final, aumentando gradualmente o tráfego para ver até que ponto uma única instância N8N pode ser pressionada.
Usando uma instância do C5.Large AWS, a implantação de modo único N8N lidou com a pressão surpreendentemente bem, como você pode ver na tabela de comparação abaixo. Enquanto este exemplo mantinha até 100 vus, Quando chegamos a 200 vus, atingimos o teto para o que uma configuração de thread única pode gerenciarcom tempos de resposta até 12 segundos e uma taxa de falha de 1%.
Quando ativamos o modo de fila, a arquitetura mais escalável da N8N que separa a ingestão da webhook da execução do fluxo de trabalho, o desempenho saltou para 72 solicitações por segundo, a latência caiu em três segundos e o sistema lidou com 200 usuários virtuais com zero falhas.
Escalando até o C5.4xlarge (16 VCPUS, 32 GB de RAM), vimos alguns ganhos impressionantes. No modo único, a taxa de transferência aumentou ligeiramente para 16,2 solicitações por segundo com melhorias modestas de latência.
Mas foi o modo de fila que realmente roubou o show. Atingimos uma consistente 162 solicitações por segundo e mantivemos isso em uma carga completa de 200 VU, com latência abaixo de 1,2 segundos e falhas zero. Esse é um ganho de taxa de transferência de 10x apenas escalando verticalmente e escolhendo a arquitetura certa.
Vários webhooks
Para o próximo teste, queríamos simular a multitarefa de nível corporativo para refletir melhor as implantações do N8N no mundo real, Por isso, configuramos 10 fluxos de trabalho distintos, cada um desencadeado por seu próprio webhook.
No C5. Large em modo único, o desempenho caiu rapidamente. Aos 50 VUS, o tempo de resposta aumentou acima de 14 segundos com uma taxa de falha de 11%. A 100 VUS, a latência atingiu 24 segundos com uma taxa de falha de 21%. E com 200 VUs, a taxa de falhas atingiu 38% e o tempo de resposta se estendeu a 34 segundos – essencialmente um colapso.
Mudar para o modo de fila mudou o jogo. Ele manteve 74 solicitações por segundo de forma consistente de três a 200 VUs, com latência dentro de limites aceitáveis e uma taxa de falha de 0%. Mesmo hardware, resultado totalmente diferente.
Mais uma vez, o C5.4xlarge levou as coisas a outro nível. No modo único, atingiu o pico de 23 solicitações por segundo com uma taxa de falha de 31%. Mas, no modo de fila, pressionamos e mantivemos 162 solicitações por segundo em todas as cargas, com falhas zero. Mesmo sob o estresse máximo, a latência permaneceu em torno de 5,8 segundos. A multitarefa em escala exige mais que o modo de músculo e fila entregue absolutamente.
Uploads de arquivo binário
Por fim, queríamos testar as tarefas mais famintas e pesadas em disco que pudéssemos, então configuramos um benchmark de dados binários com fluxos de trabalho que lidam com grandes uploads de arquivos, como imagens, PDFs e mídia.
Em um C5.Large em modo único, as rachaduras apareceram cedo. Em apenas três usuários virtuais, gerenciamos apenas três solicitações por segundo. Com 200 VUs, os tempos de resposta aumentaram e 74% dos pedidos falharam. Isso não é apenas uma desaceleração, é uma falha operacional total.
O modo de fila ofereceu um pouco mais de resiliência, adiando a quebra. Mas por 200 VUs, ele também entrou em colapso com uma taxa de falha de 87% e cargas úteis incompletas.
Então nos viramos para o C5.4xlarge. Com essa instância maior no modo único, atingimos 4,6 solicitações por segundo, o tempo de resposta aparado em um terço e reduzimos a taxa de falha de 74% para apenas 11%. Muito melhorado, mas não perfeito.
Então, no modo de fila, atingimos o pico de 5,2 solicitações por segundo e, crucialmente, manteve uma taxa de falha de 0% em todo o teste. Todo O arquivo grande foi recebido, processado e respondido com sucesso. Este teste deixou claro – não se trata apenas de arquitetura. Os fluxos de trabalho binários pesados exigem CPU grave, RAM e taxa de transferência de disco.
Takeaways -chave
Então, o que todos esses testes nos disseram?
- O modo de fila não é opcional. É o primeiro passo em direção à escalabilidade real. Mesmo em hardware básico, ele aumenta massivamente o desempenho com a configuração mínima.
- Hardware é importante. A atualização para um C5.4xlarge mais do que dobra a taxa de transferência, reduz a metade da latência e elimina completamente as taxas de falha.
- Dados binários quebram tudo – a menos que você esteja preparado. Você precisará de mais RAM, disco mais rápido, armazenamento compartilhado como S3 e trabalhadores paralelos para gerenciar tudo.
Se você estiver construindo automação para equipes internas, sistemas de back-end ou aplicativos voltados para o cliente, não espere que gargalos forcem uma atualização. Planeje a escala desde o início. Use o modo de fila para separar a ingestão do processamento, escala horizontalmente com os trabalhadores para processamento simultâneo e dimensione seu hardware para corresponder à sua carga de trabalho. Os fluxos simples precisam de menos, mas dados binários e multitarefa precisam de mais. O N8N é construído para escalar, mas, como qualquer motor, ele precisa do combustível certo e do caminho certo para atingir a potência total.
Quer testar sua própria configuração?
E aqui está o vídeo completo de benchmarking.
