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 m...@yahoo-inc.com
--
Mark Nottingham m...@yahoo-inc.com
