trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason <jason.giedy...@gmail.com>
Subject Re: Cache problems
Date Fri, 09 Jul 2010 13:45:12 GMT
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.
>

Mime
View raw message