I would like your help to clarify this n_gunzip on my varnish setup.
These are my stats for one server that is running a couple of websites.
34837 0.00 0.50 cache_hit - Cache hits
1022 0.00 0.01 cache_hitpass - Cache hits for pass
4672 0.00 0.07 cache_miss - Cache misses
2175 . . n_expired - N expired objects
85 0.00 0.00 n_gzip - Gzip operations
3512 0.00 0.05 n_gunzip - Gunzip operations
The problem is I am seeing what I think is a lot of gunzips, about 7% of all hits. I really do not believe users would be accessing my websites with browsers that do not support gzip so I cannot understand why the gunzips are happenning.
All I have related to encoding on my VCL is the following:
sub vcl_recv {
if (req.http.Accept-Encoding) {
if (req.http.Accept-Encoding ~ "gzip") {
# If the browser supports it, we'll use gzip.
set req.http.Accept-Encoding = "gzip";
}
else if (req.http.Accept-Encoding ~ "deflate") {
# Next, try deflate if it is supported.
set req.http.Accept-Encoding = "deflate";
}
else {
# Unknown algorithm. Remove it and send unencoded.
unset req.http.Accept-Encoding;
}
}
...
Is my Varnish behaving correctly? Is this normal behavior?
Gunzip is pretty cheap, so I wouldn't worry about this for your traffic levels.
If this is a Varnish 3.0 server, you can safely remove the Accept-Encoding scrubbing in vcl_recv. This will be done behind the scenes by Varnish itself.
As for a root cause, my guess is that this is your service monitoring probe that forgets to set Accept-Encoding: gzip. Your probe URL (front page/favicon/probe.txt) is stored gzip-ed inside Varnish, and these repeated checks are skewing your gzip rate.