[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