Bun vs Node.js: Um Experimento de Teste de Carga

Desde o seu lançamento, o Bun tem se destacado como uma solução promissora para desenvolvedores que buscam otimizar o desempenho das suas aplicações JavaScript. Recentemente, há um interesse crescente em utilizar o Bun em ambientes de produção.

Com isso em mente, realizar um exame prático para avaliar as vantagens de usar o Bun agora parece uma boa ideia. Hoje, vamos realizar um experimento simples de teste de carga para comparar o desempenho de uma API Express.js rodando em dois runtimes JavaScript distintos: Node.js e Bun.

Nossa análise se concentrará na avaliação de desempenho de um endpoint responsável por calcular números da sequência Fibonacci sob um alto volume de requisições.

Vamos lá!

O Código

Você pode acessar o código usado para esses testes nos links abaixo:

• Bun: Repositório
• Node.js: Repositório

O mesmo código será usado para ambos os ambientes de runtime.

Configurando no zCloud

Em seguida, vamos proceder com o deploy de ambas as APIs no zCloud.

Felizmente, configurar e implantar aplicações no zCloud é fácil.

Conforme ilustrado na imagem abaixo, implantar um aplicativo simplesmente envolve selecionar os recursos computacionais desejados, definir o nome do aplicativo, escolher a região de deploy e definir as configurações relacionadas ao Docker, como o caminho do Dockerfile do seu projeto.

Com a configuração pronta, é hora de submeter esses endpoints a testes de carga pesados.

Disparando

Vou utilizar o Autocannon, uma ferramenta de benchmarking HTTP escrita em Node.js, para executar o teste de carga. Usaremos o seguinte comando:

npx -y autocannon -c 25 -w 4 -d 60 <URL>

• A flag c determina o número de conexões simultâneas.
• w especifica o número de threads de trabalho.
• Por último, d define a duração do teste do autocannon em segundos.

Este comando resultará em duas tabelas contendo dados sobre as requisições:

Bun:

Node.js:

Agora, vamos comparar os resultados.

O Bun exibiu uma latência média de 387,36 milissegundos, atingindo um pico de 3357 milissegundos. Em contraste, o Node.js registrou uma latência média de 1112,88 milissegundos, com um pico de 3608 milissegundos.

A tabela seguinte se concentra nas estatísticas das requests. O Bun processou com sucesso cerca de 3.700 requisições, alcançando uma média de 61 requisições por segundo. Enquanto isso, o Node.js gerenciou cerca de 1.700 requisições, com uma média de cerca de 21 requisições por segundo.

Também podemos comparar as métricas usando o Grafana do zCloud. Você pode acessar os Dashboards através do link disponível na página de App Env.

Comparação

Vamos começar avaliando o uso de recursos físicos: CPU e memória.

Enquanto o Node.js utilizava totalmente a CPU alocada para o aplicativo (0.5 zCloud), o Bun atingiu apenas 60% desse valor:

Bun:

Node.js:

Em termos de uso de memória, o Bun consumiu quase a metade da memória em comparação com o Node.js:

Bun (~50MiB):

Node.js (~80MiB):

Em seguida, vamos analisar os resultados das requisições no Dashboard do Ingress.

Conforme ilustrado no gráfico abaixo, a API do Bun demonstrou a capacidade de transmitir mais de 20 KiB/s de resposta, enquanto o Node.js atingiu apenas 8 KiB/s:

Além disso, a tabela abaixo categoriza as métricas de solicitação por path e response status.

Bun:

Node.js:

O Bun lidou com quase o triplo de requisições em comparação com o Node.js, com um tempo médio de resposta menor:

3704 / 1273 ≃ 2.9

Além disso, em relação às requisições malsucedidas, o Bun exibiu uma taxa de falha de 0.4% com códigos de erro 499, enquanto o Node.js encontrou uma taxa de falha de 1.7%:

Bun:

(15 * 100) / (3704 + 15) ≃ 0.4

Node.js:

(22 * 100) / (1273 + 22) ≃ 1.7

Conclusão

Em conclusão, o Bun mostrou métricas de desempenho superiores em comparação com o Node.js, exibindo maior throughput de requisições, menor latência e utilização de memória mais eficiente.

É crucial enfatizar que essas descobertas são derivadas de testes de benchmarking de um endpoint simples. Não estamos incentivando o abandono do Node.js, nem estamos implicando sua inferioridade. Em vez disso, esses resultados fornecem informações objetivas a serem consideradas.

Além disso, o recurso de observabilidade do zCloud se mostrou excepcional. Não requer configuração adicional, proporcionando um eficiente e valioso monitoramento dos seus apps.

Não investigamos por que o Bun se saiu muito melhor numa tarefa vinculada à CPU. Se você souber explicar essa diferença, deixe um comentário abaixo com mais detalhes.

Post original (em inglês) Assista também o vídeo abordando tudo que foi falado no post.