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 [email protected]
