Return-Path: Delivered-To: apmail-trafficserver-users-archive@www.apache.org Received: (qmail 81199 invoked from network); 9 Jul 2010 13:46:44 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Jul 2010 13:46:44 -0000 Received: (qmail 68681 invoked by uid 500); 9 Jul 2010 13:46:44 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 68558 invoked by uid 500); 9 Jul 2010 13:46:41 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 68550 invoked by uid 99); 9 Jul 2010 13:46:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jul 2010 13:46:40 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jason.giedymin@gmail.com designates 209.85.216.177 as permitted sender) Received: from [209.85.216.177] (HELO mail-qy0-f177.google.com) (209.85.216.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jul 2010 13:46:33 +0000 Received: by qyk1 with SMTP id 1so3274880qyk.8 for ; Fri, 09 Jul 2010 06:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=0rzMDr8omfOEZwxEru4byF+3mg9uOPY5mg7gMhFVCNE=; b=w8yY+UBBHWjcWrHyb7KrC1R79kHJhkmGRs3wKZbYIf/T8MCysxAGuxPcHKICYvByMG SUBPqGNQ6W/S9nDfaNCGYZB+K0wUjKqivEFYswzRxucDqP861RcsufM9OXokQSBjlvmK ofvryhA8gSTRteMwg0IiYxF/x6aY8QyU5HqJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LnlPkHLbXIOMiViG5VcfNQ02llSAWMXKgWmPON1Ah+1Rz/c5eLXTcasXq5rGLIKCds akyLHNU8GgAlFrFN01Zgjw5dZmGy4a0QTegcmwlaJHzLlWQ2mMqy+MUONGpnTw4DftiA frye3NVNtYIPuUUTbakZt6JKCwe0swyNPVdbY= MIME-Version: 1.0 Received: by 10.224.2.147 with SMTP id 19mr5543862qaj.61.1278683112198; Fri, 09 Jul 2010 06:45:12 -0700 (PDT) Received: by 10.229.192.137 with HTTP; Fri, 9 Jul 2010 06:45:12 -0700 (PDT) In-Reply-To: <4C370889.6030201@cs.put.poznan.pl> References: <4C36E8AA.5050309@cs.put.poznan.pl> <4C370889.6030201@cs.put.poznan.pl> Date: Fri, 9 Jul 2010 09:45:12 -0400 Message-ID: Subject: Re: Cache problems From: Jason To: users@trafficserver.apache.org Content-Type: multipart/alternative; boundary=0015175ca840aed48d048af49cca X-Virus-Checked: Checked by ClamAV on apache.org --0015175ca840aed48d048af49cca Content-Type: text/plain; charset=ISO-8859-1 Generally, TS becomes the gateway so TS will check if the content is cached prior to sending upstream unless told not too. Can you try testing a static page (html) and limiting your connects to 1-10 so you can debug at least. TS adheres to the standard http headers, so basically anything outlined there is fair game for TS: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html Can you provide (again) the following config files: remap.config records.config storage.config On Fri, Jul 9, 2010 at 7:31 AM, Marcin Bazydlo < marcin.bazydlo@cs.put.poznan.pl> wrote: > Thanks for the answer! > > I personally would first try to resolve the connection issue. The logs >> are warning of too many connections. After that I would start debugging >> the cache control. >> > > That's what we did. The first two points happend when there was only one > user connecting to ts. > I was simply doing curl to make sure caching works. My problem is I cannot > exactly determine caching algorithm. When does ts decide that page should be > cached? How size of the document influences this decision? > > After thinking about point number 2 little more I thought that maybe I get > response faster then it gets into cache? Is it possible that often changed > resource will never get into cache? > For example: > Client makes request, cache decides it is miss and sends req to server and > then response back to client. Client receives request and makes the same > request again immediately. Cache didn't had time to save response to disk so > it marks it as miss and forwards req to server. Because response2 is > different then response1 so cache starts to insert it into cache, and then > client makes another request... > My colleague thinks it is not the case, but I still had to to ask. :-D. > > > > Can you limit your connections from your script to see if there is a >> consistent throttle in place? >> > Yes we can. But real problem is that ts didn't get stabilized after we > stopped script. > Our test generates 200, 400, 700 and 1000 concurent requests. Logs say that > ts is being restarted, that's fine, but why cannot I connect to it then? > Netstat even says that ts is listening, just I get no response. :-( > > To make it clear. The throttling problem is from separate test then this > caching experiments. > > thanks in advance, > m. > --0015175ca840aed48d048af49cca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Generally, TS becomes the gateway so TS will check if the content is cached= prior to sending upstream unless told not too.

Can you = try testing a static page (html) and limiting your connects to 1-10 so you = can debug at least.

TS adheres to the standard http headers, so basically a= nything outlined there is fair game for TS:

Can you provide (again) the following config files:
remap.config
records.config
storage.config
=



On Fri, J= ul 9, 2010 at 7:31 AM, Marcin Bazydlo <marcin.bazydlo@cs.put.poznan.pl>= wrote:
Thanks for the answer!
I personally would first try to resolve the connection issue. The logs
are warning of too many connections. After that I would start debugging
the cache control.

That's what we did. The first two points happend when there was only on= e user connecting to ts.
I was simply doing curl to make sure caching works. My problem is I cannot = exactly determine caching algorithm. When does ts decide that page should b= e cached? How size of the document influences this decision?

After thinking about point number 2 little more I thought that maybe I get = response faster then it gets into cache? Is it possible that often changed = resource will never get into cache?
For example:
Client makes request, cache decides it is miss and sends req to server and = then response back to client. Client receives request and makes the same re= quest again immediately. Cache didn't had time to save response to disk= so it marks it as miss and forwards req to server. Because response2 is di= fferent then response1 so cache starts to insert it into cache, and then cl= ient makes another request...
My colleague thinks it is not the case, but I still had to to ask. :-D.


Can you limit your connections from your script to see if there is a
consistent throttle in place?
Yes we can. But real problem is that ts didn't get stabilized after we = stopped script.
Our test generates 200, 400, 700 and 1000 concurent requests. Logs say that= ts is being restarted, that's fine, but why cannot I connect to it the= n?
Netstat even says that ts is listening, just I get no response. :-(

To make it clear. The throttling problem is from separate test then this ca= ching experiments.

thanks in advance,
m.

--0015175ca840aed48d048af49cca--