Dimensionando uma aplicação node.js, nginx como servidor base, mas verniz ou redis para caching?

Question

Eu não estou perto de ser bem versado em usar nginx ou verniz, mas esta é a minha configuração no momento.

Eu tenho um servidor node.js em execução que serve json, templates html ou eventos socket.io. Então eu tenho o nginx rodando na frente do nó que está servindo todo o conteúdo estático (css, js, etc.).

Neste ponto, gostaria de armazenar em cache o conteúdo estático e o conteúdo dinâmico na memória.

No meu entender, o verniz pode armazenar em cache o conteúdo estático muito bem e não exigiria que eu tomasse o código do meu aplicativo. Eu também acho que é capaz de armazenar em cache conteúdo dinâmico também, mas não pode haver nenhum cabeçalho de cookie?

Eu uso redis no momento para armazenar os dados da sessão e planejei usá-los para outras coisas no futuro, como acompanhar estatísticas não cruciais, mas divertidas.

Eu não tenho ideia de como lidar com o cache de tudo no site. Eu acho que se resume a essas opções, mas pode haver mais:

1. Jogue o verniz na frente do nginx e deixe o verniz armazenar em cache páginas estáticas, sem alterações no código do aplicativo. O Redis armazenaria em cache as chamadas dinâmicas do banco de dados, o que exigiria a modificação do código do aplicativo.

2. Ignore completamente o verniz e deixe os redis manipularem o armazenamento em cache de tudo, depois use um dos módulos nginx-redis. Não tenho certeza se isso exigiria muitas alterações no código do aplicativo (para os arquivos estáticos).

Eu não estou tendo nenhuma sorte em encontrar benchmarks que comparam nginx + verniz vs nginx + redis e eu sou muito inexperiente para bancar isso sozinho (altas chances de minhas configurações serem horríveis).

Estou basicamente procurando a solução que seria a mais eficiente em termos de req / se escalável no futuro (lançar novo hardware no problema + talvez ajustar alguns valores em uma configuração = novos servidores ativos e em execução -podidamente).

    

Answer 1

Para o conteúdo puramente estático, você normalmente ganha muito pouca vantagem executando o Varnish na frente de qualquer servidor da Web maduro, como o nginx ou o Apache. (Não posso falar de node.js porque ainda não o usei.) A razão para isso é que o kernel mantém um cache de sistema de arquivos que armazena arquivos acessados recentemente na RAM. É possível que o Varnish faça um trabalho um pouco melhor que o kernel ao escolher exatamente quais arquivos para manter no cache e quais ejetar, mas também é possível que ele faça um trabalho pior. Isso dependerá do que mais seu sistema faz, bem como das diferenças nas políticas de retenção de cache. A latência extra causada por ter um proxy na frente do seu servidor da Web excederá em muito qualquer diferença entre o armazenamento em cache do Varnish e do sistema de arquivos do kernel.

Você está correto quanto a Varnish não armazenar em cache as respostas enviadas com um Set-Cookie: header . Ele também ignora o cache, se a solicitação contiver um cabeçalho Cookie: . A razão para isso é que haverá uma resposta única para cada usuário que visitar uma determinada página e é improvável que cada usuário faça uma nova visita à mesma página, o que significa que seu cache estaria cheio de entidades que nunca serão usadas.

Varnish pode armazenar conteúdo dinâmico em cache e é aí que ele brilha. Digamos que a primeira página do seu site requer uma compilação de código PHP e 20 consultas de banco de dados em caches frios. Em caches quentes (APC, memcached, Redis, cache de consulta do MySQL, etc.) ele ainda requer pesquisas para o memcached / Redis e fazendo um stat() em cada arquivo PHP incluído na requisição. Supondo que você tenha um site razoavelmente bem otimizado, ainda assim é provável que este seja pelo menos 1/10 de segundo (e isso é muito bem otimizado; 1 - 3 segundos inteiros são muito mais comuns na minha experiência). O verniz ficará feliz em servir a mesma página em menos de 1/1000 de segundo. Mas isso significa que seus usuários não podem estar logados na primeira página do seu site, porque eles não podem obter seus Cookie: cabeçalhos, mas se isso for aceitável para você, o Varnish é uma vitória fácil.

O verniz também requer cabeçalhos de cache corretos . Se não tiver certeza de que é seguro armazenar um objeto em cache, não será. Se você atender a todos esses requisitos, o verniz pode ser a ferramenta para você. Dito isso, apenas colocar os cabeçalhos corretos no lugar fará com que os clientes armazenem em cache o conteúdo em si, o que pode fazer uma diferença muito maior do que a do Varnish.

Se você não tiver a experiência necessária para avaliar sua configuração, agora é a hora de ter essa experiência. Você está comparando para avaliar a adequação de suas configurações. Tente algo e execute ab sobre ele e, em seguida, altere uma coisa um e execute ab exatamente da mesma maneira em relação a essa configuração. Agora você sabe qual é "melhor". Enxaguar, repita. (Além disso, sempre execute ab duas vezes e ignore o primeiro resultado. Isso fará com que você teste somente os caches quentes e não acabe pensando erroneamente que uma configuração é pior porque foi testada em caches frios.)

Arquitetar uma solução escalonável para o seu site é um tópico complexo o suficiente para que não caiba em uma resposta do ServerFault. Certamente podemos ajudar com partes individuais disso (como "Como dimensionar meu servidor de memcached para um cluster de memcached?") Quando você se deparar com esses problemas.

Outras leituras:

Eu escrevi uma resposta há um tempo atrás, que tinha uma seção sobre encontrando o gargalo quando benchmarking .
Recentemente, o Womble me apontou para um excelente post sobre como encontrar gargalos .