Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (nike.apache.org: domain of szymon_francuzik@op.pl
 designates 213.180.142.137 as permitted sender)
Message-ID: <4C3B110E.3030008@op.pl>
Date: Mon, 12 Jul 2010 14:56:46 +0200
From: Szymon Francuzik <szymon_francuzik@op.pl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.8) Gecko/20100306 Iceowl/1.0b1 Icedove/3.0.3
MIME-Version: 1.0
To: users@trafficserver.apache.org
Subject: Re: Cache problems
References: <4C36E8AA.5050309@cs.put.poznan.pl>
	<DF46AF89-BD1D-4E25-B402-4719AFCD2A3C@gmail.com>
	<4C370889.6030201@cs.put.poznan.pl>
 <AANLkTinWW2-JoqrqfJ7QqtxzCvfcTXZ0yT7wjTkVBUn7@mail.gmail.com>
 <4C373273.2060801@cs.put.poznan.pl> <4C373433.7030306@apache.org>
In-Reply-To: <4C373433.7030306@apache.org>
Content-Type: multipart/alternative;
 boundary="------------000209010507080801020706"

This is a multi-part message in MIME format.
--------------000209010507080801020706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09.07.2010 16:37, Leif Hedstrom 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.
>>
I tried testing a static page and it's worked ok (page is cached after 
first request).

> 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).
traffic_server works all the time. traffic_server, traffic_cop and 
traffic_manager have the same start time.
> 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.

Header from the origin server (for dynamic page):

HTTP/1.1 200 OK
Date: Mon, 12 Jul 2010 12:20:04 GMT
Server: Apache/2.2.15 (Unix)
Content-Type: text/html; charset=utf-8

Header from  the origin server for static page (cached after first 
request):

HTTP/1.1 200 OK
Date: Mon, 12 Jul 2010 12:20:08 GMT
Server: Apache/2.2.15 (Unix)
Last-Modified: Mon, 12 Jul 2010 09:58:50 GMT
ETag: "48a4e2-2aabd-48b2dcca50a80"
Accept-Ranges: bytes
Content-Length: 174781
Content-Type: text/plain

TS doesn't use ETag (even if I replace static page, ts responses with 
cached version). It looks like 'Last-Modified' is crucial. We set 
attributes proxy.config.http.cache.required_headers INT 0 and 
proxy.config.http.cache.when_to_revalidate INT 3 (never stale), so we 
didn't expect this header to be required by TS.

--------------000209010507080801020706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<div class="moz-text-flowed"
 style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">On
09.07.2010 16:37, Leif Hedstrom wrote:
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">
  <blockquote type="cite" style="color: rgb(0, 0, 0);">On 07/09/2010
03:47 PM, Jason wrote:
    <br>
    <br>
&nbsp;Can you try testing a static page (html) and limiting your connects
    <br>
&nbsp;to 1-10 so you can debug at least.
    <br>
    <br>
  </blockquote>
</blockquote>
I tried testing a static page and it's worked ok (page is cached after
first request).
<br>
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">I addition to what
Jason said, a few things to try:
  <br>
  <br>
1) Make sure traffic_cop isn't killing traffic_server.&nbsp; 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).
  <br>
</blockquote>
traffic_server works all the time. traffic_server, traffic_cop and
traffic_manager have the same start time.
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">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.
  <br>
</blockquote>
<br>
Header from the origin server (for dynamic page):
<br>
<br>
HTTP/1.1 200 OK
<br>
Date: Mon, 12 Jul 2010 12:20:04 GMT
<br>
Server: Apache/2.2.15 (Unix)
<br>
Content-Type: text/html; charset=utf-8
<br>
<br>
Header from&nbsp; the origin server for static page (cached after first
request):
<br>
<br>
HTTP/1.1 200 OK
<br>
Date: Mon, 12 Jul 2010 12:20:08 GMT
<br>
Server: Apache/2.2.15 (Unix)
<br>
Last-Modified: Mon, 12 Jul 2010 09:58:50 GMT
<br>
ETag: "48a4e2-2aabd-48b2dcca50a80"
<br>
Accept-Ranges: bytes
<br>
Content-Length: 174781
<br>
Content-Type: text/plain
<br>
<br>
TS doesn't use ETag (even if I replace static page, ts responses with
cached version). It looks like 'Last-Modified' is crucial. We set
attributes proxy.config.http.cache.required_headers INT 0 and
proxy.config.http.cache.when_to_revalidate INT 3 (never stale), so we
didn't expect this header to be required by TS.
<br>
</div>
</body>
</html>

--------------000209010507080801020706--