Http compressão e desempenho gzip

Question

Eu sempre tentei ativar a compactação gzip nos servidores da web porque ela parecia ter um custo de CPU muito baixo e você obtinha uma redução significativa na transferência de dados.

Agora eu tenho um servidor público que não tem o gzip ativado e, às vezes, a carga da CPU é bastante alta sob tráfego intenso (principalmente porque consultas SQL complexas em determinadas páginas) e a leitura este artigo da Microsoft sobre o assunto da ativação, a carga da CPU deve ser levada em conta ao ativar o gzip.

O cliente quer reduzir o tempo de carregamento da largura de banda e da velocidade, mas não tenho certeza se a ativação do gzip fará mais mal do que bem, embora tenha funcionado bem em outros servidores.

Na sua experiência, a compactação gzip terá um impacto significativo na carga da CPU?

EDIT: Neste caso, estamos usando o IIS6

    

Answer 1

A questão-chave é "quantos dados estão sendo compactados?".

Se você estiver executando uma consulta de banco de dados enorme que leva um número considerável de segundos para ser executada e a página resultante tiver algumas dezenas de Kb, a despesa de compactar os dados será completamente reduzida à custa do SQL trabalhe ao ponto onde não há nenhum ponto sequer pensando sobre isto. Uma CPU moderna vai comprimir dezenas ou centenas de Kb praticamente instantaneamente, em comparação com qualquer consulta de DB.

Outro fator a favor da compactação é que, configuradas corretamente, as páginas estáticas não são compactadas novamente em cada solicitação e os objetos que não serão beneficiados (arquivos de imagem e outros que são pré-compactados) não são compactados pelo servidor da Web em absoluto. Somente conteúdo dinâmico provável de ser compressível precisa ser compactado em cada solicitação.

Em geral, a menos que você tenha razão específica para compactar, eu recomendo fazê-lo. O custo da CPU é geralmente pequeno, a menos que você esteja executando o servidor web em um nível baixo. -dispositivo de energia (como um roteador doméstico, por exemplo) por algum motivo. Uma razão para não compactar é scripts que usam técnicas de "pesquisa longa" para emular eficientemente o envio de servidor ou scripts que alimentam o conteúdo por gotejamento para o navegador para indicação de progresso - o buffer implícito pela compactação dinâmica pode fazer com que essas solicitações excedam o tempo limite no cliente lado, mas com uma configuração cuidadosa, você pode adicioná-los à lista "não compactar" enquanto ainda compactar todo o resto. Outro motivo para considerar não usar as compactações dinâmicas é que adiciona um pouco de latência a cada solicitação dinâmica, embora, para a maioria das aplicações da Web, essa diferença seja completamente insignificante em comparação com a economia de largura de banda.

Uma nota lateral sobre a carga da CPU devido a consultas SQL: isso implica que o conjunto de dados de trabalho para essas consultas é pequeno o suficiente para caber na RAM (caso contrário, seu desempenho seria vinculado a E / S em vez de CPU) um GoodThing (tm). A alta carga de CPU pode ser devida apenas ao número de consultas simultâneas, como é suspeito, mas também pode ser que alguns deles são objetos de varredura de tabela que estão na RAM alocada do SQL e / ou no cache do sistema operacional (ou são de outra forma fazendo o seu trabalho o caminho mais longo), então pode valer a pena registrar consultas demoradas e checar se há alguma melhoria de indexação ou outras otimizações que você possa usar para reduzir o conjunto de trabalho em que operam.

    

Answer 2

Ativar a compactação GZIP não deve afetar significativamente a carga da sua CPU. Apenas no caso, você também deve verificar o seu consumo de memória, porque agora você precisará armazenar mais dados na memória antes de enviá-los (a menos que a compactação GZIP aconteça sem o buffer de texto sem formatação). Às vezes, a lixeira de cache pode acabar fazendo com que as coisas fiquem muito lentas para um servidor da Web.