Ir para conteúdo

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Michel Wilhelm

Nginx vs Varnish

Recommended Posts

Olá pessoal!

 

Estou migrando um sistema de milhares de acessos diários com muita concorrência e gerando milhões de pageviews por mês. Atualmente a stack abaixo aguenta muito bem, mas tem tido algumas lentidões para quem posta os conteudos, e em testes vimos que atualizar o PHP 5.6 para o PHP 7.0 resolve este problema além  de estar ja 100% compatível com a aplicação:

 

- 1 droplet na Digital Ocean 1GB que contem a aplicação

- 1 droplet na Digital Ocean 1GB para o Banco de dados

- MySQL

- Varnish (porta 80)

- Nginx (outra porta, recebe o tráfego do Varnish)

- PHP 5.6

 

Estive pesquisando e vi que agora o Nginx pode fazer o mesmo trabalho do Varnish e muito bem. Porém, gostaria de saber se alguém já efetuou alguns testes relacionados ao Nginx Cache em um ambiente com muitos acessos.

A stack final possivelmente será:

 

- 1 droplet na Digital Ocean 1GB que contem a aplicação

- 1 droplet na Digital Ocean 1GB para o Banco de dados

- MySQL

- Nginx (outra porta, recebe o tráfego do Varnish)

- PHP 7.0

 

Qualquer informação a respeito, agradeço

 

Compartilhar este post


Link para o post
Compartilhar em outros sites
Em 2/12/2017 at 13:43, Michel Wilhelm disse:

Porém, gostaria de saber se alguém já efetuou alguns testes relacionados ao Nginx Cache em um ambiente com muitos acessos.

 

 

Eu uso atualmente nginx cache em produção, numa média de 3k rpm. Como a plataforma que trabalho é um e-commerce, configurei para ser um cache curtíssimo de apenas 2 minutos.

 

Atende muito bem e preferi usar o cache no nginx (cache distribuído) em vez de usar varnish pela simplicidade da arquitetura (um software a menos, menos máquinas para dar manutenção) e também por trabalhar com auto scaling, coisa que não ficaria "muito legal" com o varnish, já que ele não consegue resolver DNS (IPs dinâmicos).

 

Uma outra área possui um cache maior de 20 minutos, que é validado na primeira resposta com sucesso. (essa área inclusive é nginx + php [wordpress], também com cache, pois são outros nginx.).
Nisso eu ganhei ao passar menos requests para o backend, e por ser um cache, o tempo do First Byte quando dá HIT no cache é bem menor do que quando o o proxy passa e solicita para a aplicação. 

 

Posso citar apenas um ponto negativo dessa escolha:

-> O cache ser distribuido, então como tenho 4 máquinas rodando a app, para os requests passarem a dar 100% de HIT, precisa bater ao menos 1 vez em cada uma das 4. (eu poderia ter configurado um memcache ou redis, para ter um cache centralizado, ao qual todos os nginx escrevessem e lessem, mas não foi necessário até o momento para nossa solução).

 

No meu caso funciona assim, pois tenho:

Citar

 

-> 1 Elastic Load Balancer na frente de

     -> 4 máquinas com Nginx (proxy_pass com proxy_cache)

           -> NodeJS (aplicação)

 

 

Compartilhar este post


Link para o post
Compartilhar em outros sites

 

Bacana seu comentário, isso me deixa com mais segurança para continuar com essa stack.

Está usando S3 para distribuir os arquivos ou monta um local na instância?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Estou usando CDN (cloudinary) para os estáticos. Ele tem integração com o s3.
Eu faço upload pro s3, e a cloudinary faz fetch nos arquivos lá e depois cacheia na CDN deles.

Compartilhar este post


Link para o post
Compartilhar em outros sites

  • Conteúdo Similar

    • Por Good
      Boa tarde,
       
      temos um servidor na amazon, e o site está direcionado para o servidor. Estamos tendo um problema, de vez em quando o servidor cai. 
       
      Gostaríamos de saber se tem algum programa no ubuntu, que monitore qual arquivo que teve alto consumo. Para sabermos se o código está escrito de maneira complexa, causando a queda do servidor.
       
      Eu lembro que uma vez a hostgator mandou um relatório, avisando que tal arquivo estava consumindo muito do servidor. É possível fazer esse monitoramento? Não temos como ficar 24h olhando por exemplo o htop..
       
      Aguardo uma resposta,
      obrigado!
    • Por iamdiegoinacio
      Eu consigo acessar o meu site com iptvaiomi.com, mas quando eu coloco o www ele não entra e aparece a mesagem: Erro 503 service Temporarily Unavailable. Como resolver?
    • Por ulissestoga
      Estou utilizando nginx na amazon ec2, utilizo um sistema laravel para carregamento de imagens. Tanto as imagens em KB ou MB, demora muito o carregamento via upload. Gostaria de uma ajuda para implementar no nginx algum modulo que deixe o carregamento mais rapido. Utilizo nginx 1.10.2.
      Obrigado
    • Por dnielrodrigues
      Tentei mudar o usuário do Nginx de "www-data" para o usuário "ubuntu" (que é o padrão quando logamos por SSH no servidor amazon). O motivo é porque o git já seta o usuário dos arquivos como o mesmo que você está usando o git. E fica chato ficar mudando o grupo/permissóes dos arquivos toda vida que algo é atualizado.



      No apache eu alterava o usuário "www-data" no arquivo de configuração e funcionava de boa.



      Mas no Nginx eu mudei no arquivo nginx.conf e ele sempre dá erro 500 agora.



      Já tentei dar restart e stop/start no service. Também tentei dar reboot na instância. Mas nada rolou.



      Alguém saberia como fazer essa configuração de forma segura.

    • Por dnielrodrigues
      Tentei mudar o usuário do Nginx de "www-data" para o usuário "ubuntu" (que é o padrão quando logamos por SSH no servidor amazon). O motivo é porque o git já seta o usuário dos arquivos como o mesmo que você está usando o git. E fica chato ficar mudando o grupo/permissóes dos arquivos toda vida que algo é atualizado.
      No apache eu alterava o usuário "www-data" no arquivo de configuração e funcionava de boa.
      Mas no Nginx eu mudei no arquivo nginx.conf e ele sempre dá erro 500 agora.
      Já tentei dar restart e stop/start no service. Também tentei dar reboot na instância. Mas nada rolou.
×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.