Re: [squid-users] collapsed_forwarding not working as expected

On 17/11/2011 3:52 p.m., Schwenker, Stephen wrote:
> Hey Amos,
>
> Here are the details you asked for. I hope you see something in it that I don't.
>
>
> Steve.
>
>
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Wednesday, November 16, 2011 4:07 PM
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] collapsed_forwarding not working as expected
>
>
> On Wed, 16 Nov 2011 13:49:23 -0500, Schwenker, Stephen wrote:
>> Hello,
>>
>> We've installed squid as an accelerator for our website, and it's
>> working pretty well, but we have found out that the collapsed
>> forwarding
>> is not working as expected. We ran some load tests to a single url
>> with
>> a 1 minute expiry and squid is still sending approximately 12000
>> request
>> to the back end server in a 5 minute span. If I understand the
>> documentation correctly, squid should only send 5 requests to the
>> back
>> end server.
> Object variance can affect that. 5 requests is the best-case scenario
> for a single static object representation.
>
> What are the reply headers coming back with the object?
>
>
> Here are the response coming back that I've captured from fiddler using my browser.
>
> HTTP/1.1 200 OK
> Cache-Control: public
> Content-Type: text/html; charset=utf-8
> Expires: Thu, 17 Nov 2011 02:41:53 GMT
> Last-Modified: Thu, 17 Nov 2011 02:41:08 GMT
> Vary: Accept-Encoding

I think it might be that Vary: header. Collapse can't really determine
objects as identical if the header mentioned differs from the existing
client downloads one.

An ETag header to identify whether the original object instance has
changed may be worth adding.

> Server: Microsoft-IIS/7.0
> X-AspNetMvc-Version: 3.0
> X-AspNet-Version: 4.0.30319
> X-Powered-By: ASP.NET
> WS: 2-3
> Date: Thu, 17 Nov 2011 02:41:08 GMT
> Content-Length: 21
>
> 11/16/2011 9:41:08 PM
>
>
>
>
>> I've configured the following.
>>
>> http_port 80 accel defaultsite=<site name> vhost
>> cache_peer<web server> parent 80 7 no-query no-digest originserver
>> sourcehash monitorurl=/statuscheck/ name=<web server> http11
>>
>> ... acls
>> ... header access
> Your "header access" re-writing may also affect the responses. What are
> these lines?
>
>
> Here is the section with the header_access rules
>
> minimum_expiry_time 30 seconds
> cache_vary on
> header_access X-Powered-By deny all
> header_access X-AspNetMvc-Version deny all
> header_access X-AspNet-Version deny all
> header_access Server deny all
> via off

Okay, good, those should not be affecting it.

Amos
Received on Thu Nov 17 2011 - 11:07:28 MST