O verniz 3 executa gunzip mesmo que o pipeline inteiro tenha sido zipado

1

Estou refatorando minha VCL Varnish e não consigo descobrir essa coisa.

O Varnish 3.0 suporta nativamente o conteúdo gzipped, e essencialmente parece fazer a coisa certa. Veja também: link

No entanto, o Varnish ainda executa uma etapa de gunzip, de acordo com o vernizlog, embora o cliente solicite conteúdo compactado e o back-end responda com conteúdo compactado com gzip. De acordo com a documentação do Varnish, o Varnish usa o padrão do_gzip = true, e também armazena os objetos do cache compactados. Então, por que o gunzip?

Aqui estão as entradas de registro relevantes:

11 RxURL        c /javascripts/general.js
11 RxHeader     c Accept-Encoding: deflate, gzip
11 VCL_call     c fetch
13 TxHeader     b Accept-Encoding: gzip
13 RxHeader     b Content-Encoding: gzip
13 RxHeader     b Content-Type: application/javascript
11 Gzip         c u F - 1554 4476 80 80 12365
11 VCL_call     c deliver
11 TxHeader     c Content-Encoding: gzip

Como você pode ver, o pipeline inteiro suporta gzip, mas o Varnish executa um gunzip durante o vcl_fetch. Eu presumo que ele armazena os objetos compactados, e como você pode ver, ele também é compactado.

Após este pedido, varnishstat mostra a operação do gunzip:

$ varnishstat -1 | grep zip
n_gzip                       0         0.00 Gzip operations
n_gunzip                     1         0.00 Gunzip operations

Nota: Minha VCL tem nenhuma configuração gzip, nem faço nada com o corpo do objeto. Eu estou confiando nos padrões sensíveis, portanto, não estou mostrando o VCL.

Uma operação gunzip é relativamente leve, mas eu ainda gostaria de entender por que, e possivelmente evitar algumas centenas de milhares de operações.

    
por Martijn Heemels 10.01.2013 / 12:27

1 resposta

0

Você pode por favor colocar isso na sua seção vcl_fetch ()

set beresp.do_gunzip = false;

Isso deve parar o verniz fazendo o gzip.

    
por 10.01.2013 / 13:07