Problemas com HTTP Compression?
-
03-07-2019 - |
Pergunta
Estamos investigando o uso de compactação HTTP em um aplicativo que está sendo servido por JBoss. Depois de fazer a alteração de configuração no Tomcat SAR, estamos vendo uma compressão de cerca de 80% - este é, obviamente, grande, no entanto eu quero ser cauteloso ... antes de implementar este sistema grande problemas, tem alguém aí encontradas utilizando HTTP Compression?
Um par de pontos a serem observados para a minha situação.
- Nós temos o controle total sobre navegador - assim toda a empresa usa o IE6 / 7
- O aplicativo é apenas interna
- Durante o teste de carga, o nosso servidor aplicativo estava sob carga relativamente pequena - o DB foi o nosso gargalo
- Nós temos controle sobre as máquinas clientes e todos eles obter uma verificação de especificações (processador decente / 2GB RAM)
Todas as experiências com este seria muito apreciada!
Solução
Enquanto você respeitar cabeçalho Accept-Encoding
do cliente corretamente (ou seja, não servem arquivos compactados para os clientes que podem não descompactá-los), você não deve ter um problema.
Ah, e lembre-se que deflate é mais rápido do que gzip .
Outras dicas
A compressão não é considerado exótico ou bleeding edge e (fwiw) Eu não ouvi falar de ou correr em quaisquer problemas com ele.
A compressão na mosca pode aumentar a carga da CPU no servidor. Se em todos os possíveis recursos estáticos pré-compressão e cache de respostas dinâmicas comprimido pode combater isso.
É apenas uma idéia realmente boa a toda a volta. Ele irá adicionar a carga da CPU leve para o seu servidor, mas isso geralmente não é o gargalo. Isso fará com que suas páginas carregam mais rápido, e você vai usar menos largura de banda.