Como um site como o rambler oferece conteúdo dinâmico tão rápido? Ainda mais rápido que o Yahoo (que tem um servidor no meu país - sudeste da Ásia; o rambler não funciona).
Isso é puramente a capacidade do Nginx? Onde devo estar olhando para aprender sobre tais capacidades?
Praticamente um novato aqui, acredito que o serverfault.com, se servido do Nginx, será muito mais rápido do que o IIS 7 (supondo que o tempo de acesso do banco de dados seja o mesmo em ambos os casos). Isso é uma suposição justa?
Editar:
Publique no Karl usando Nginx na frente do IIS7
Você pode ver esta apresentação para ter uma visão geral dos recursos internos do nginx. A principal diferença é a manipulação assíncrona de solicitações, em vez de usar encadeamentos como o Apache. Você pode dar uma olhada em esta documentação também.
How does a site like rambler serve dynamic content so fast? ... Is this purely Nginx’s capability? Where should I be looking into to learn about such capabilities?
Isso tem pouco ou nada a ver com o servidor da Web usado - tanto 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 serviço da 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 'frontend' , significando HTML, CSS, Javascript e Imagens, o número deles, o tamanho deles e a entrega adequada (compactação HTTP, armazenamento em cache ) destes.
É claro que a velocidade do servidor ainda é importante, não estou dizendo que ela deva ser ignorada ou que não importa. Mas normalmente é a menor parte percebida da velocidade do usuário final - o trabalho no servidor é feito frequentemente em menos de 500 milissegundos, mas a página não está pronta antes de 3.000 - 5.000 milissegundos terem passado. A maior parte desse tempo vai para o download dos recursos frontend (CSS, Javascript, Images).
Steve Souders fez o trabalho original, enquanto 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 fazer sites rápidos. O mesmo material que está em seu livro pode ser encontrado em conversa em vídeo , e estas 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 por meio do testador do WebPageTest.org - que lhe dará uma boa impressão da parte frontal desses sites e por que eles são mais rápidos ou mais lentos.
I believe that serverfault.com if served from Nginx will be much faster the IIS 7 (assuming db access time to be same in both the case). Is this a fair assumption?
Não, isso é um mal-entendido. : -)
O Nginx é mais usado para balanceamento de carga de outros aplicativos / servidores e veiculação de conteúdo estático do que para o servidor completo.
Por exemplo, você pode escrever um aplicativo usando uma das muitas estruturas python e ter o nginx como front-end para muitas instâncias desse tipo (talvez espalhadas por várias máquinas). Neste caso, os servidores nginx têm duas finalidades: ele lida com pedidos de conteúdo estático como imagens e folhas de estilo diretamente (e devido ao seu design faz isso muito rapidamente), e passa solicitações dinâmicas para o aplicativo espalhando a carga entre todas as instâncias que conhece. Esta é uma configuração muito popular na comunidade Ruby on Rails também.
Existem dois outros motivos possíveis pelos quais o Rambler pode aparecer mais rápido para você do que o serviço local do Yahoo. Em primeiro lugar, o PoP local do Yahoo pode não ter recursos suficientes para atender ao número de solicitações que recebe mais rapidamente, então talvez simplesmente adicionar mais hardware (supondo que o software se adapte bem dessa forma) aceleraria (mas, presumivelmente, a diferença não é vale o custo de manter o kit extra ou o Yahoo teria feito isso). A outra grande diferença pode estar no back-end do que no servidor web - os dois serviços terão, sem dúvida, arranjos muito diferentes de bancos de dados e mesmo que não estejam correndo exatamente a mesma variedade de consultas (e a quantidade de hardware dedicado à arquitetura de 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 resulta em uma única resposta simples - há muitas maneiras de criar um aplicativo que se destina a vários milhares de usuários, cada um com seus próprios benefícios, problemas & compromissos e mesmo se você considerar todas essas diferenças em cada site, haverá uma dinâmica de base de usuários diferente, além de haver problemas de rede além do controle dos designers.
nginx possivelmente, mas arquitetura mais escalável 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 alguns CDNs.
se você estiver interessado no assunto - confira este e isso e .. bem - google; -]
Os melhores sites usam aceleradores de aplicativos, como os ZXTMs do Zeus - eles podem armazenar em cache respostas dinâmicas em muitos casos, o que obviamente é de grande benefício.
Aqui está uma boa explicação: link
Eu tenho dificuldade em ver o serverfault muito mais rápido (por exemplo, o SO pode ter problemas de carga devido ao tráfego?), já que é uma carga de página instantânea aqui na UE no meu caminho. É muito mais rápido e mais responsivo 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 vem de entre o servidor e o usuário final imo 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 do país 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 / mudar a menos que você saiba que é onde 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.