Existe algum benchmark ou comparação que seja mais rápido: coloque o nginx na frente do nó e deixe-o servir arquivos estáticos diretamente ou use apenas o nó e servir arquivos estáticos usando-o?
A solução nginx parece ser mais administrável para mim, alguma ideia?
Respostas:
Terei que discordar das respostas aqui. Embora o Node funcione bem, o nginx definitivamente será mais rápido quando configurado corretamente. O nginx é implementado com eficiência em C seguindo um padrão semelhante (retornando a uma conexão apenas quando necessário) com uma pequena pegada de memória. Além disso, ele suporta o sendfile syscall para servir aqueles arquivos, o que é o mais rápido possível para servir arquivos, uma vez que é o próprio kernel do SO que está fazendo o trabalho.
Até agora, o nginx se tornou o padrão de fato como servidor front-end. Você pode usá-lo para seu desempenho no fornecimento de arquivos estáticos, gzip, SSL e até mesmo no balanceamento de carga mais tarde.
PS: Isso pressupõe que os arquivos são realmente "estáticos", como em repouso no disco no momento da solicitação.
sendfile- mas parece que você precisa escrever algum código, consulte, por exemplo. blog.std.in/2010/09/09/using-sendfile-with-nodejs
Fiz um teste rápido ab -n 10000 -c 100para servir um byte 1406 estático favicon.ico, comparando nginx, Express.js (middleware estático) e Express.js em cluster. Espero que isto ajude:
Infelizmente, não posso testar 1.000 ou mesmo 10.000 solicitações simultâneas, pois o nginx, na minha máquina, começará a gerar erros.
EDITAR : conforme sugerido por artvolk, aqui estão os resultados do cluster + staticmiddleware (mais lento):
staticmiddleware de cache fará na produção.
Eu tenho uma interpretação diferente dos gráficos de @gremo. Parece-me que tanto o nó quanto o nginx são dimensionados com o mesmo número de solicitações (entre 9 e 10k). Claro que a latência na resposta para nginx é menor em 20 ms constantes, mas não acho que os usuários necessariamente perceberão essa diferença (se seu aplicativo for bem construído). Dado um número fixo de máquinas, levaria uma quantidade bastante significativa de carga antes de converter uma máquina de nó em nginx, considerando que o nó é onde a maior parte da carga ocorrerá em primeiro lugar. O único contraponto a isso é se você já está dedicando uma máquina ao nginx para balanceamento de carga. Se for esse o caso, você também pode fazer com que ele sirva ao seu conteúdo estático.
De qualquer forma, eu configuraria o Nginx para armazenar os arquivos estáticos ... você verá uma diferença ENORME aí. Então, quer você os atenda a partir do nó ou não, você está basicamente obtendo o mesmo desempenho e o mesmo alívio de carga em seu aplicativo de nó.
Eu pessoalmente não gosto da ideia de meu front-end Nginx servindo ativos estáticos na maioria dos casos, em que
1) O projeto agora deve estar na mesma máquina - ou deve ser dividido em ativos (na máquina nginx) e aplicativo da web (em várias máquinas para escalonamento)
2) A configuração do Nginx agora precisa manter os locais do caminho para ativos estáticos / recarregar quando eles mudam.
Essa é uma pergunta difícil de responder. Se você escreveu um servidor de nó realmente leve para servir apenas arquivos estáticos, provavelmente teria um desempenho melhor do que o nginx, mas não é tão simples. ( Aqui está um "benchmark" comparando um servidor de arquivos nodejs e lighttpd - que é semelhante em desempenho ao ngingx ao servir arquivos estáticos).
O desempenho em relação ao serviço de arquivos estáticos geralmente se resume a mais do que apenas o servidor da Web que faz o trabalho. Se você quiser o melhor desempenho possível, usará um CDN para servir seus arquivos para reduzir a latência para os usuários finais e se beneficiar do cache de borda.
Se você não estiver preocupado com isso, o node pode servir arquivos estáticos muito bem na maioria das situações. O Node se presta a código assíncrono, do qual também depende, uma vez que é de thread único e qualquer E / S de bloqueio pode bloquear todo o processo e degradar o desempenho de seus aplicativos. É mais do que provável que você esteja escrevendo seu código de maneira não bloqueadora, mas se estiver fazendo algo de forma síncrona, poderá causar bloqueio, o que degradaria a rapidez com que outros clientes podem ter seus arquivos estáticos servidos. A solução fácil é não escrever código de bloqueio, mas às vezes isso não é uma possibilidade ou nem sempre é possível aplicá-lo.
Estou certo de que puramente node.js pode superar nginx em muitos aspectos.
Dito isso, o NginX tem um cache embutido, enquanto o node.js não vem com ele instalado de fábrica (VOCÊ PRECISA CONSTRUIR SEU PRÓPRIO CACHE DE ARQUIVOS). O cache de arquivo personalizado supera o nginx e qualquer outro servidor no mercado, pois é super simples.
Além disso, o Nginx é executado em vários núcleos. Para usar todo o potencial do Node, você deve agrupar os servidores do nó. Se você estiver interessado em saber como, por favor, pm.
Você precisa cavar fundo para alcançar o nirvana de desempenho com o nó, esse é o único problema. Uma vez feito o inferno, sim ... é melhor do que Nginx.