Existem impactos no desempenho do uso do gzip para serviços da web?

Question

Eu tenho um cenário muito típico:

navegador - > servidor da web - > serviço da web

Eu vi muitos artigos / documentação sobre o benefício de compactar os dados enviados do servidor Web para o navegador para economizar largura de banda, mas estou pensando se há benefícios semelhantes para compactar os dados entre o serviço da Web e o servidor web?

O XML deve compactar muito pequeno, então é claro que obteríamos os mesmos benefícios em termos de largura de banda, mas estou especificamente imaginando se isso será compensado pela capacidade de processamento necessária no servidor da Web para descriptografar as mensagens SOAP que recebe.

Alguém já ativou o gzip para serviços da web e houve alguma melhoria no desempenho?

Para essa questão, os clientes de serviços da web até mesmo entenderão gzip em primeiro lugar? Ou ativar a criptografia seria uma perda de tempo, que nunca seria aproveitada pelo cliente de serviços da Web?

    

Answer 1

A questão se resume ao que seu servidor tem de sobra - CPU ou largura de banda? Se você está constantemente esperando pela rede, mas a sua CPU está inativa, então provavelmente você deve estar olhando para a compressão. Se sua CPU está ocupada, mas você não está enviando muitos dados, a compactação provavelmente não é para você.

O XML é uma linguagem muito detalhada (e mais importante, repetitiva), portanto, a compactação provavelmente fará uma diferença decente na quantidade de dados transmitidos.

A compressão só é útil se ambos os lados a suportarem, caso contrário, inverter o interruptor não fará nada. A publicidade que você suporta a compactação faz pouca diferença se a compactação não for realmente usada.

Finalmente, não é necessariamente tudo ou nada se você é quem está transmitindo. A compressão Gzip (LZ77) é ajustável para otimizar velocidade, tamanho ou algo entre eles. Como esse ajuste é feito depende da sua implementação, mas apenas o lado ENVIANDO os dados decide. A descompactação de dados gzip'ed altamente compactados não requer mais recursos do que a descompactação de dados que foram apenas levemente compactados, portanto, o destinatário não deve se importar de qualquer maneira.

    

Answer 2

Como você afirmou, o servidor envia cabeçalhos à medida que o conteúdo é compactado e o navegador o descriptografa.

Se você quiser fazer isso entre seu servidor web e serviço web, já que seu serviço NÃO é um navegador, você mesmo leu os cabeçalhos (ou assume tudo que é gzipado) e você usaria gzipdecode antes de enviar a solicitação ao manipulador SOAP.

A menos que você não transmita muitos dados para frente e para trás (o que vale a pena compactar) não vejo nenhum benefício vindo dele. Mesmo quando a compactação é benéfica, se você não tiver CPU e RAM suficientes para suportá-la, isso pode ser fatal.

Espero que ajude, D

    

Answer 3

Vendo como o gZip é manipulado pelo navegador do usuário, o cliente da web na outra extremidade precisa entender como descompactar o gzip. Você será capaz de dizer isso procurando nos cabeçalhos. IIRC é o cabeçalho "accept", e você está procurando por "gzip" e "deflate".

A sobrecarga de codificação / decodificação para o gzip é razoavelmente nominal, mas está lá. É útil em navegadores porque não são particularmente oportunos - o usuário ficará sentado irritado até o carregamento da página. Um serviço da web é um pouco diferente, eles geralmente precisam ser muito rápidos, ou então todo o aplicativo parece ter sido interrompido.

A única vez que eu sugiro que gzip seria útil em um serviço web seria se fosse um serviço trivial que será martelado milhares de vezes por dia, onde a economia de 10kb a 2kb de XML valeria o processamento despesas gerais. E isso supondo que o serviço da Web do outro lado possa aceitar o gzip em primeiro lugar.

    

Answer 4

BTW, lembre-se de que os dados binários gzip podem resultar em mais informações e não menos. Portanto, em qualquer caso, você deve estar ciente do tipo de dado que está sendo compactado.