trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <zw...@apache.org>
Subject Re: Cache problems
Date Fri, 09 Jul 2010 14:37:39 GMT
On 07/09/2010 08:30 AM, Marcin Bazydlo wrote:
> On 07/09/2010 03:47 PM, Jason wrote:
>
> > Can you try testing a static page (html) and limiting your connects
> > to 1-10 so you can debug at least.
> Yes on Monday Szymon will do two more tests:
> - static page
> - page that is dynamic but doesn't change content
>
>> Also, try turning these on for testing in the mean time
>> proxy.config.http.cache_urls_that_look_dynamic 1
>> proxy.config.http.cache.http 1
> Sure we turned those on (as shown in configs from first mail :-)). 
> Context is following that we want to cache REST service.
> And content is changed only through POST, PUT and DELETE. So we made 
> those configurations changes as first thing :-D.

I addition to what Jason said, a few things to try:

1) Make sure traffic_cop isn't killing traffic_server.  I had this 
happen to me once, and it shows up as if the cache is blown away 
(because the directory is never flushed to disk). This could happen if 
the health check from traffic_cop to traffic_server fails. This is easy 
to see, for example, just check the "start" time of traffic_server vs 
traffic_manager (they should usually be the same).

2) I'd really like to see the complete header from the Origin server, to 
make sure there is nothing in the response that prevents TS from caching 
the response.

3) Finally, an extremely useful debugging tool is to run traffic_server 
with the debug tracer enabled. You can do that via records.config, or, 
which is what I usually do, from command line. For example, a good 
diagnostic tracer for you to try is

     $ sudo /usr/local/bin/traffic_server -T 'http.*'


The output from this will be pretty verbose, so just send one request 
through the system, and step through all the diagnostics.

As a side note; The argument to -T (or the records.config setting) is a 
regular expression, and when enabled, all tracer messages that matches 
that regex is displayed. With tracers disabled (the default), the 
overhead of having these diagnostics messages in the code is virtually 
zero, but when enabled, it gets very, very expensive (so never run with 
it enabled in production).

Cheers,

-- leif


Mime
View raw message