Re: problems collapsing large responses

A bit more;

  - it *does* hit VARY_REFRESH first
  - threshold for the vary problem is much lower
  - evident since (at least) Squid 2.7STABLE1

On 15/02/2010, at 8:59 PM, Mark Nottingham wrote:

> I'm seeing some strange behaviour when using collapsed_forwarding on large responses in squid-2.7 and squid2-HEAD.
>
> Two separate symptoms:
> 1) large responses not being cached when collapsed
> 2) large responses not being completely sent; i.e., part of the response is sent, then it 'locks up'
>
> #2 is more worrisome.
>
> To recreate:
> - compile a squid-2.7 or HEAD, configure with collapsed_forwarding on
> - serve content with a script like this:
>
> ---8<---
> #!/usr/bin/env python
>
> import sys, time
> time.sleep(2)
> print "Status: 200 OK"
> print "Content-Type: text/plain"
> print "Cache-Control: max-age=45"
> print "Vary: Accept-Encoding"
> print
> for i in range(1024):
> print "abcdefghij" * 12
> --->8---
>
> and drive traffic like this:
> httperf --server localhost --port 3128 --hog --num-calls 1 --num-conns 10 --rate 2 --uri `cat urls.txt`
> or this:
> http_load -rate 2 -seconds 20 -proxy localhost:3128 urls.txt
> assuring that the cache is empty first.
>
> See access.log as well as load generation results.
>
> Observations:
> - there seems to be a threshold response size of somewhere around 110K that triggers this
> - does not appear to rely on value of maximum_object_size_in_memory
> - does not appear to be specific to disk or null disk caching
> - problem #2 seems to be caused by a Vary header
> - does not appear to be related to VARY_RESTART; clientCacheHit: Vary MATCH!
>
> Does this seem familiar to anyone? I'll file a bug, but thought I'd check and see if it was a known issue.
>
> Cheers,
>
>
> --
> Mark Nottingham mnot_at_yahoo-inc.com
>
>

--
Mark Nottingham       mnot_at_yahoo-inc.com