Por que o Nginx é tão rápido?


31

Como um site como o rambler exibe conteúdo dinâmico tão rápido? Ainda mais rápido que o Yahoo (que possui um servidor no meu país - sudeste da Ásia; o passeador não).

Isso é puramente a capacidade do Nginx? Onde devo procurar para aprender sobre esses recursos?

Praticamente um novato aqui, acredito que o serverfault.com, se servido pelo Nginx, será muito mais rápido no IIS 7 (assumindo que o tempo de acesso ao banco de dados seja o mesmo nos dois casos). Esta é uma suposição justa?

Editar:

Postagem de Karl usando o Nginx na frente do IIS7


Observe que serverfault.com já usa o Nginx (de acordo com o Wappalyzer ). : P
WillS

Respostas:


26

Você pode ver esta apresentação para uma visão geral dos nginx internals. A principal diferença é o tratamento assíncrono de solicitações, em vez de usar threads, como o Apache. Você pode dar uma olhada nesta documentação também.


2
Boa resposta quanto à arquitetura do nginx e ao problema C10K. No entanto, entendo que a pergunta dos OP seja sobre a velocidade percebida de carregamento da página, que tem pouco a ver com o nginx.
Jesper H

O que significa "assíncrono" realmente significa? Eu sempre pensei que isso significa executado em um segmento separado.
27712 Ivan Ivan

O Nginx médio assíncrono age sempre como um proxy, mesmo com o Php: Nginx recebe a solicitação HTTP, envia para o servidor Php, MAS não bloqueia / espera para enviar a resposta HTTP. É por isso que você vê uma diferença (velocidade, CPU / RAM) no site de alto tráfego. Mas não há nenhum ganho de desempenho por alguns pedidos (que dizem respeito a 95% da internet ....), mas Nginx é legal ;-)
Thomas Decaux

21

Como um site como o rambler exibe conteúdo dinâmico tão rápido? ... Isso é puramente a capacidade do Nginx? Onde devo procurar para aprender sobre esses recursos?

Isso tem pouco ou nada a ver com o servidor web usado - o nginx, o IIS e o Apache são 'rápidos o suficiente' e geralmente fazem seu trabalho em milissegundos. O nginx é muito mais rápido que o Apache, mas isso significa apenas que o proprietário do site precisará de menos servidores para a parte de exibição na web - o nginx não transfere dados mais rapidamente para você.

A parte menos importante é a velocidade do servidor , ou seja, o tempo necessário para criar o HTML. A parte mais importante é o desempenho do 'frontend' , com o qual quero dizer o HTML, CSS, Javascript e Imagens, o número deles, o tamanho deles e a entrega adequada (compactação HTTP, armazenamento em cache) deles.

É claro que a velocidade do servidor ainda é importante, não estou dizendo que deva ser ignorada ou que não importa. Mas normalmente é a menor parte percebida da velocidade do usuário final - o trabalho do servidor geralmente é realizado em menos de 500 milissegundos, mas a página não está pronta antes de 3.000 a 5.000 milissegundos. A maior parte desse tempo vai para o download dos recursos de front-end (CSS, Javascript, Imagens).

Steve Souders fez o trabalho original enquanto estava no Yahoo, ele agora está trabalhando no Google. Seu primeiro livro "Sites de alto desempenho" é o melhor ponto de partida para aprender mais sobre como criar sites rápidos. O mesmo material que está em seu livro pode ser encontrado nesta conversa em vídeo e nestas regras de design . No entanto, acho que o livro é rápido de ler e muito mais fácil de entender.

Você pode executar os sites através do testador do WebPageTest.org - o que lhe dará uma boa idéia da parte frontend desses sites e por que eles são mais rápidos ou mais lentos.

Acredito que serverfault.com, se servido pelo Nginx, será muito mais rápido no IIS 7 (assumindo que o tempo de acesso ao banco de dados seja o mesmo nos dois casos). Esta é uma suposição justa?

Não, isso é um mal-entendido. :-)


18

O Nginx é mais frequentemente usado para balancear a carga de outros aplicativos / servidores e veicular conteúdo estático do que é usado como servidor completo.

Por exemplo, você pode escrever um aplicativo usando uma das muitas estruturas python e o nginx é o front-end de muitas instâncias (talvez espalhadas por várias máquinas). Nesse caso, o nginx serve dois propósitos: ele lida diretamente com solicitações de conteúdo estático, como imagens e folhas de estilo (e, devido ao seu design, faz isso muito rapidamente), e passa solicitações dinâmicas ao aplicativo, espalhando a carga entre todas as instâncias que conhece. . Essa é uma configuração muito popular na comunidade Ruby on Rails também.

Há duas outras razões possíveis pelas quais o Rambler pode parecer mais rápido do que o serviço local do Yahoo. Em primeiro lugar, o Yahoo PoP local pode não ter recursos suficientes disponíveis para atender ao número de solicitações mais rápidas, então talvez simplesmente adicionar mais hardware (supondo que o software seja bem dimensionado dessa maneira) o acelere (mas, presumivelmente, a diferença não é vale o custo de manutenção do kit extra ou o Yahoo teria feito isso). A outra grande diferença pode estar no back-end, e não no servidor da web - os dois serviços sem dúvida terão arranjos de banco de dados muito diferentes e, mesmo que não estejam, provavelmente não estarão executando exatamente a mesma variedade de consultas (e a quantidade de hardware dedicado à arquitetura do banco de dados também terá um efeito significativo).

Analisar por que um serviço é mais rápido que outro (geralmente ou em circunstâncias específicas) geralmente não resultará em uma única resposta simples - existem várias maneiras de projetar um aplicativo que se destina a expandir para muitos milhares de usuários, cada um com seu seus próprios benefícios, problemas e compromissos e, mesmo que você considere todas essas diferenças, cada site terá uma dinâmica diferente na base de usuários, além de haver problemas de rede além do controle dos designers.


3

Arquitetura possivelmente mais escalável do nginx com balanceamento de carga razoável na frente de servidores de conteúdo estático / geradores de conteúdo dinâmico. se você realmente deseja obter uma ótima experiência do usuário final, provavelmente deve mover o conteúdo para mais perto dos 'olhos' - use alguma CDN.

se você estiver interessado no assunto - confira isso e aquilo e ... bem - google; -]


2

Os melhores sites usam aceleradores de aplicativos como os ZXTMs da Zeus - eles podem armazenar em cache respostas dinâmicas em muitos casos, o que obviamente é de grande benefício.



0

É difícil ver a falha do servidor muito mais rápido (talvez o SO tenha problemas de carregamento devido ao tráfego, talvez?), Pois já é um carregamento instantâneo de página aqui na UE ao longo do meu percurso. É muito mais rápido e ágil do que a maioria dos sites de notícias locais e assim por diante.

A maioria dos problemas óbvios com tempos de carregamento e latência ocorre entre o servidor e o usuário final e não o desempenho real do servidor (a menos que alguém tenha dimensionado ou projetado algo errado). Sites diferentes podem ser roteados de maneiras diferentes e há uma grande possibilidade de que um site local para mim tenha uma latência maior do que algo em todo o planeta - tudo depende de tantas variáveis ​​que você não pode dizer que é solucionável apenas por um serviço atualizar / alternar, a menos que você saiba que é aí que está o problema para um uso específico (r) ...

Obviamente, o cache de vários tipos no servidor faz uma grande diferença, mas todos esses sites já fazem isso até onde eu sei.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.