<div dir="ltr">Oooooooh, thanks Dridi for checking, I was wrong.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 13, 2017 at 11:27 AM, Dridi Boukelmoune <span dir="ltr"><<a href="mailto:dridi@varni.sh" target="_blank">dridi@varni.sh</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Apr 13, 2017 at 8:44 AM, Guillaume Quintard<br>
<<a href="mailto:guillaume@varnish-software.com">guillaume@varnish-software.<wbr>com</a>> wrote:<br>
> You are right, subsequent requests will just be passed to the backend, so no<br>
> gzip manipulation/processing will occur.<br>
<br>
</span>I had no idea [1] so I wrote a test case [2] to clear up my doubts:<br>
<br>
    varnishtest "uncacheable gzip"<br>
<br>
    server s1 {<br>
        rxreq<br>
        txresp -bodylen 100<br>
    } -start<br>
<br>
    varnish v1 -vcl+backend {<br>
        sub vcl_backend_response {<br>
            set beresp.do_gzip = true;<br>
            set beresp.uncacheable = true;<br>
            return (deliver);<br>
        }<br>
    } -start<br>
<br>
    client c1 {<br>
        txreq<br>
        rxresp<br>
    } -run<br>
<br>
    varnish v1 -expect n_gzip == 1<br>
    varnish v1 -expect n_gunzip == 1<br>
<br>
Despite the fact that the response is not cached, it is actually<br>
gzipped, because in all cases backend responses are buffered through<br>
storage (in this case Transient). It means that for clients that don't<br>
advertise gzip support like in this example, on passed transactions<br>
you will effectively waste cycles on doing both on-the-fly gzip and<br>
gunzip for a single client transaction.<br>
<br>
That being said, it might be worth it if you have a high rate of<br>
non-cacheable contents, but suitable for compression: less transient<br>
storage consumption. I'd say it's a trade off between CPU and memory,<br>
depending on what you wish to preserve you can decide how to go about<br>
that.<br>
<br>
You can even do on-the-fly gzip on passed transactions only if the<br>
client supports it and the backend doesn't, so that you save storage<br>
and bandwidth, at the expense of CPU time you'd have consumed on the<br>
client side if you wanted to save bandwidth anyway.<br>
<br>
The only caveat I see is the handling of the built-in VCL:<br>
<span class=""><br>
> I am wondering if it is safe to do this even on responses that may<br>
> subsequently get set as uncacheable by later code?<br>
<br>
</span>If you let your VCL flow through the built-in rules, then you have no<br>
way to cancel the do_gzip if the response is marked as uncacheable.<br>
<br>
Dridi<br>
<br>
[1] well I had an idea that turned out to be correct, but wasn't sure<br>
[2] tested only with 5.0, but I'm convinced it is stable behavior for 4.0+<br>
</blockquote></div><br></div>