Re: [squid-users] Squid-2.7STABLE7: problem with Vary

Krzysztof Olędzki wrote:
> On 2010-03-20 02:29, Amos Jeffries wrote:
>> Krzysztof Olędzki wrote:
>>> Hello,
> Hello,
>
>>> I'm have been trying to configure Squid to store and provide two
>>> versions of the same obiect, but so far with no luck.
>>>
>>> I configured my load balancer to append an additional header to
>>> a request depending on a client status, something like:
>>> "X-ASP-CFlag: Yes" or "X-ASP-CFlag: No"
>>>
>>> I also configured my servers to append "Vary: X-ASP-CFlag" and to
>>> set a different ETag for both responses.
>>>
>>> Squid is able to cache such responses and always provide a correct
>>> version, so I believe I did everyting correct releated to handling
>>> Vary& ETag.
>>>
>>> My problem is that each time, when a different type of client comes,
>>> the object is RELEASED and Squid fetches a new one. So, Squid
>>> is able to provide a cached version of such obiect as long as
>>> consecutive requests come from the same type of a client. If they comes
>>> from the different type, then I get 0% hit rate. :(
>>
>> Is Vary always set regardless of X-ASP-CFlag presence?
>
> Yes, Vary should be always set and the same goes for X-ASP-CFlag.
>
>> missing X-ASP-CFlag is considered to be one of the three variant cases
>> by Squid (missing, "Yes", "No").
>
> It is not possible for X-ASP-CFlag to be empty.
>
>> Is the ETag the same for both variants?
>
> No.
>
>> What does Cache-Control: header contain for each/both?
>
> Don't know. I'll check this. Does it make any different if they are
> distinct?
>

Not really if they are different. What matters is the content, what CC
is instructing Squid to do.

This goes for Cache-Control: header in both the request AND reply.

If either contains no-store, private, no-cache, must-revalidate, or a
maxage < the stored object age Squid is forced to re-fetch and replace
the relevant objects.

>>> 1269025015.033 23 192.168.162.1/192.168.152.2 TCP_MISS/200
>>> 16857 GET http://www.example.com/xml/EF.001.xml -
>>> FIRST_UP_PARENT/192.168.162.1 text/xml
>>> 1269025022.400 27 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16886 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025022.863 81 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16886 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025022.967 25 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16886 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025023.456 1 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16886 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025024.015 21 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16886 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025024.101 16 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16887 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025025.836 1 192.168.162.1/192.168.152.2 TCP_MEM_HIT/200
>>> 16887 GET http://www.example.com/xml/EF.001.xml - NONE/- text/xml
>>> 1269025028.506 27 192.168.162.1/192.168.152.2 TCP_MISS/200
>>> 100934 GET http://www.example.com/xml/EF.001.xml -
>>> FIRST_UP_PARENT/192.168.162.1 text/xml
>>
>> ... client B first request.
>>
>>> 1269025031.030 37 192.168.162.1/192.168.152.2 TCP_MISS/200
>>> 16904 GET http://www.example.com/xml/EF.001.xml -
>>> FIRST_UP_PARENT/192.168.162.1 text/xml
>>> 1269025033.208 11 192.168.162.1/192.168.152.2 TCP_MISS/200
>>> 100934 GET http://www.example.com/xml/EF.001.xml -
>>> FIRST_UP_PARENT/192.168.162.1 text/xml
>>
>> ... client B second request.
>>
>> Notice how the object size keeps changing with each TCP_MISS. Might be
>> related.
>
> The size is different because the object is different. :)
>
>>> According to the store.log I have:
>>>
>>> - request from a client type "A":
>>> 1269025015.023 RELEASE 00 00032DDE 3670265D41E40D46FB58467B0A406016
>>> 200 1269025002 1268659805 1269025062 text/css -1/16369 GET
>>> http://www.example.com/css/EF.001.css
>>> 1269025015.023 SWAPOUT 00 000332CA 26DF93F5ACF8EFF960D1ABD01F1D9509
>>> 200 1269025015 -1 1269125015 x-squid-internal/vary -1/220 GET
>>> http://www.example.com/css/EF.001.css
>>> 1269025015.023 RELEASE 00 00032F03 BA73564A12C40FB51174FE3CD14F2BDA
>>> 200 1269025005 -1 1269125005 x-squid-internal/vary -1/220 GET
>>> http://www.example.com/css/EF.001.css
>>> 1269025015.033 SWAPOUT 00 000332CC E3A743051428428E9D4D45836CB2719C
>>> 200 1269025014 1268659805 1269025074 text/css -1/16338 GET
>>> http://www.example.com/css/EF.001.css
>>>
>>> - request from a client type "B":
>>> 1269025028.491 RELEASE 00 00032F04 F7F9BF630687B86AFAA4D5CD729E6F15
>>> 200 1269025005 1268659805 -1 text/xml 100483/100483 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025028.491 SWAPOUT 00 00033BEA 26DF93F5ACF8EFF960D1ABD01F1D9509
>>> 200 1269025028 -1 1269125028 x-squid-internal/vary -1/220 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025028.491 RELEASE 00 000332CA 80E0AD812ADE72183FD2BF19D3D1F251
>>> 200 1269025015 -1 1269125015 x-squid-internal/vary -1/-218 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025028.506 SWAPOUT 00 00033BF0 A070DC36FD8ED3452573EE7DC398DF53
>>> 200 1269025028 1268659805 1269025088 text/xml 100483/100483 GET
>>> http://www.example.com/xml/EF.001.xml
>>>
>>> - request from a client type "A":
>>> 1269025031.015 RELEASE 00 000332CC BCB90FADA1A3A323B25925C4776B64AB
>>> 200 1269025014 1268659805 1269025074 text/xml -1/16338 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025031.015 SWAPOUT 00 00033D2D 26DF93F5ACF8EFF960D1ABD01F1D9509
>>> 200 1269025031 -1 1269125031 x-squid-internal/vary -1/220 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025031.015 RELEASE 00 00033BEA C4D3004363864A9BC877E75165903539
>>> 200 1269025028 -1 1269125028 x-squid-internal/vary -1/220 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025031.028 SWAPOUT 00 00033D2A E3A743051428428E9D4D45836CB2719C
>>> 200 1269025030 1268659805 1269025090 text/xml -1/16385 GET
>>> http://www.example.com/xml/EF.001.xml
>>>
>>> - request from a client type "B":
>>> 1269025033.204 RELEASE 00 00033BF0 4A2CE9062319A7E381086826978BCBB3
>>> 200 1269025028 1268659805 1269025088 text/xml 100483/100483 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025033.204 SWAPOUT 00 00033EE7 26DF93F5ACF8EFF960D1ABD01F1D9509
>>> 200 1269025033 -1 1269125033 x-squid-internal/vary -1/220 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025033.204 RELEASE 00 00033D2D C5D2959AD4FB3A19CB4333A21A85A3F9
>>> 200 1269025031 -1 1269125031 x-squid-internal/vary -1/-218 GET
>>> http://www.example.com/xml/EF.001.xml
>>> 1269025033.208 SWAPOUT 00 00033EE8 A070DC36FD8ED3452573EE7DC398DF53
>>> 200 1269025032 1268659805 1269025092 text/xml 100483/100483 GET
>>> http://www.example.com/xml/EF.001.xml
>>>
>>> And so on...
>>>
>>> So, the question is: how to teach squid to do it in the right way?
>>
>> Client A and B are requesting different objects one is a CSS one an XML
>> file.
>>
>> There is no sign in access.log of those client A requests.
>
> My bad, please s/css/xml/g. I made a mistake in masking real addresses
> in the above example, but each time it was exactly the same url.
>

In that case ... that trace is clearly showing that A is storing its own
object and B is storing another, the request for A in the middle
replaces the original A object leaving the B one present. Then the
followup B replaces the original B object leaving the A one present.

Vary storing itself seems to be working, but something else is causing
the variants to be replace on each of their requests. This smells more
like a Cache-Control problem.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25
   Current Beta Squid 3.1.0.18