You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@trafficserver.apache.org by "Henry C." <he...@cityweb.co.za> on 2011/10/18 13:15:19 UTC

Trying to understand caching inconsistency with dynamic URLs (or cookies)

Hi,

Using ATS 3.0.1 on CentOS 5.x.
Setup for reverse proxy (ie, as a web accelerator)

I'm having a bit of difficulty understanding the inconsistency in caching
behaviour in my test setup.

I've simplified things down to a single traffic server, and connecting from
three different IP addresses spread across three different subnets.

Basically, what I expect is that if a page is cached, it *must* be served to
any new/same client irrespective of client no-cache, and irrespective of where
the request is coming from, etc.

What I'm seeing though is the following behaviour (say, for URL "test.com/?a=1"):

>From  Hit/Miss  Expecting
----  --------  ---------
IP1:  Miss      Miss
IP2:  Miss*     Hit
IP3:  Miss*     Hit

*=problem

If I repeat the exercise from all three IPs for the same URL then the
behaviour is as expected:

>From  Hit/Miss  Expecting
----  --------  ---------
IP1:  Hit       Hit
IP2:  Hit       Hit
IP3:  Hit       Hit

This has probably something to do with dynamic URLs since the landing page
(http://test.com/ - ie, without '?a=...') is always served as a HIT from the
cache from any IP.  ... or maybe cookies?

My config (I think these are the ones which are relevant):
CONFIG proxy.config.http.cache.http INT 1
CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1
CONFIG proxy.config.http.cache.ims_on_client_no_cache INT 1
CONFIG proxy.config.http.cache.ignore_server_no_cache INT 1
CONFIG proxy.config.http.cache.ignore_client_cc_max_age INT 1
CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 1
CONFIG proxy.config.http.cache.when_to_revalidate INT 3
CONFIG proxy.config.reverse_proxy.enabled INT 1
CONFIG proxy.config.url_remap.remap_required INT 1
CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1

~# traffic_line -r proxy.process.cluster.nodes
1

I must be missing something obvious and would appreciate any pointers.

-- 
Regards
Henry

Re: Trying to understand caching inconsistency with dynamic URLs (or cookies)

Posted by Eric Ahn <by...@gmail.com>.

Wow There is way to process easily, great..

Eric iPhone

2011. 10. 31. 오전 1:34 "Henry C." <he...@cityweb.co.za> 작성:

> On Sat, October 29, 2011 15:59, Igor GaliÄ‡ wrote:
>>> ie:
>>> browserX loads and caches page1. browserY loads page1, but for some reason
>>> the cached page1 is not served.
>>> 
>>> /me wanders off to stare at more HTTP headers, ...
>>> 
>> 
>> Maybe instead of staring at them you might want to share them with
>> us so we can help you :)
> 
> Hi Igor,
> 
> Nothing to do with dynamic URLs...
> 
> It turns out that proxies (ATS included) are respecting some or other RFC to
> identify cache objects based not only on the requested URL, but also on the
> requesting HTTP headers.
> 
> I confirmed this by using several machines and making sure that each was using
> the *exact* same browser user-agent/cache headers.  When I did this, the
> cached object was served up to all the clients, irrespective of who cached the
> object.
> 
> Anyway, I never did solve this problem completely (I didn't need to, luckily)
> - I have a query page which receives requests, it then uses PHP's curl to
> fetch (via the same ats cluster which customers hit) a resource-expensive
> object from back-end servers.  That last request always uses the same
> user-agent/cache headers (curl), so it is *always* the same irrespective of
> the original request from the client who hits our servers from the outside;
> because of this the heavy objects are cached beautifully by ats
> 
> /sidebar:  it would be great if ats had a config option to "normalise" these
> headers so that an object is seen as cached by all clients.  That would
> probably break something or other, I suppose.  However, for our case, it's a
> deal-killer NOT having it.  Fortunately we could work around this limitation.
> 
> Apologies if my description was a bit disjointed.
> 
> -- 
> Regards
> Henry
>