problems collapsing large responses

From: Mark Nottingham <mnot_at_yahoo-inc.com>
Date: Mon, 15 Feb 2010 20:59:49 +1100

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
Received 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