trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ming.zym@gmail.com" <ming....@gmail.com>
Subject Re: Suggestions for cachine dynamic content
Date Wed, 10 Aug 2011 03:50:27 GMT
for question #1:
proxy.config.http.record_tcp_mem_hit will help you get a TCP_MEM_HIT in
the squid log of trafficserver.

FYI

在 2011-08-09二的 12:55 -0600,Leif Hedstrom写道:
> On 08/09/2011 12:38 PM, Karri Vrkreddy wrote:
> > Hi,
> >     We are using ATS as reverse proxy. 
> >     In our use case most of the data is dynamic ( responses from the backend hosts
) and need not be cached for more than 5-10 mins.
> >
> >     We currently configured it to have a disk cache size of 10 GB and we left the
proxy.config.cache.ram_cache.size as -1. So that would give us a ram cache size of 10 MB.
> >      Here are my questions :
> >
> >      1. Since the ram cache size is very small, does a TCP_HIT mean a disk access
 ? ( this is a 16 GB node and lots of free memory, so I mostly buffer cache plays a
> 
> I don't think we distinguish between RAM vs disk cache in the squid 
> logs, I'm not even sure it's possible to configure a log that does it 
> either. In fact, I think there was an RFE to add such log data.
> 
> However, you can certainly see how much RAM cache hit ratio vs disk 
> cache hit ratio you get, in the stats. That's not per request though.
> 
> 10MB seems like an *incredibly* small RAM cache. Make it bigger ;).
> 
> >          significant role )
> >      2. Given the nature of the data ( not required to cache for more than 10 min
), any specific suggestions to make ATS more efficient ?
> 
> Well, with such a small cache, 10GB, I'd spend a few hundred $'s and put 
> it on SSD. It'll make it wicked fast. To use the cache efficiently, tune 
> the minimum object size setting (in records.config) to be close to your 
> average / typical size. The default is 8K, which is fairly reasonable, 
> but if your objects are significantly bigger (or smaller) than this, 
> you'll use the cache more efficiently by tuning it.
> 
> >      3.  As far as I can understand from the documentation, it looks like only highly
used objects will go to Ram Cache. According to that in our use case only few will
> >           it there. Any tweaks or change in algorithms to move as much as possible
to Ram Cache.
> 
> It will only keep the "most used" objects in RAM cache. With such a 
> small RAM cache as yours, that's probably very few objects, and you are 
> more likely to suffer from cache evictions happening much more frequent 
> than you'd want. Again, you ought to have a bigger RAM cache, I mean, a 
> couple of gig RAM today is like 50 bucks.
> 
> If memory is truly a scarce resource, you can try to enable the 
> compression feature on the RAM. It can save some memory on objects that 
> are not already gzip'ed.
> 
> 
> Cheers,
> 
> -- Leif
> 



Mime
View raw message