[Varnish] #1698: compressed objects over allocate when content-length is specified
    Varnish 
    varnish-bugs at varnish-cache.org
       
    Mon Apr  6 23:30:35 CEST 2015
    
    
  
#1698: compressed objects over allocate when content-length is specified
---------------------+----------------------
 Reporter:  dward84  |       Type:  defect
   Status:  new      |   Priority:  normal
Milestone:           |  Component:  varnishd
  Version:  4.0.3    |   Severity:  normal
 Keywords:           |
---------------------+----------------------
 Varnish appears to be allocating the uncompressed object size when
 1. Declaring beresp.do_gzip (so that the server compresses content when it
 stores it in cache)
 2. The server returns content-length
 This results in excessive memory consumption.
 As an attempted work-around, I tried removing the content-length header in
 vcl_backend_response, which doesn't work.
 The following test shows that more than 40K is allocated for what
 compresses down to several hundred bytes.
 {{{
 varnishtest "bloated object size"
 server s1 {
     rxreq
     # add -nolen here to remove Content-Length. it will just allocate the
 fetch_chunksize, passing the test.
     txresp -bodylen 40000
 } -start
 varnish v1 -arg "-s malloc,1M" \
            -arg "-pgzip_level=8" \
            -arg "-phttp_gzip_support=true" \
            -arg "-pfetch_chunksize=4k" \
            -vcl+backend {
     sub vcl_backend_response {
         set beresp.do_gzip = true;
         set beresp.ttl = 1m;
         # This doesn't work... but should it?
         unset beresp.http.Content-Length;
     }
 } -start
 client c1 {
     txreq -url "/foo"
     rxresp
     expect resp.bodylen == 40000
 } -run
 varnish v1 -expect SMA.s0.g_bytes <= 40000
 }}}
 Is this expected behavior? If so, is there a workaround?
-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1698>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
    
    
More information about the varnish-bugs
mailing list