You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Karri Vrkreddy <kv...@ymail.com> on 2011/08/09 20:38:14 UTC
Suggestions for cachine dynamic content
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
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 ?
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.
Please feel free to list out any specific suggestions for configuring YTS regarding this particular use case.
--
Thanks very much for your time,
Karri
Re: Suggestions for cachine dynamic content
Posted by "ming.zym@gmail.com" <mi...@gmail.com>.
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
>
Re: Suggestions for cachine dynamic content
Posted by Leif Hedstrom <zw...@apache.org>.
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