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.comReceived on Mon Feb 15 2010 - 10:00:34 MST
This archive was generated by hypermail 2.2.0 : Tue Feb 16 2010 - 12:00:08 MST