trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Maidment <>
Subject RE: why does cache hit rate tail off?
Date Wed, 14 Jul 2010 16:35:02 GMT
Sorry, I don’t know why I didn’t spot that!  Having increased the cache capacity, the measured
hit rate now exactly matches the expected hit rate.

From: Leif Hedstrom []
Sent: 14 July 2010 17:12
Cc: Rob Maidment
Subject: Re: why does cache hit rate tail off?

On 07/14/2010 10:02 AM, Rob Maidment wrote:

The old (LRU) algorithm made little difference.
I guess it could be that I’m simply exceeding the cache capacity.  The test uses a working
set of 2.24GB.  How do I configure the size of the cache?

Two settings:

In etc/trafficserver/storage.config, you will see a line similar to

    var/trafficserver 140M

You'll want that closer to  2.24G I imagine :). For the RAM cache, the setting is in etc/trafficserver/records.config:

    CONFIG proxy.config.cache.ram_cache.size INT -1

The default (-1) means it'll calculate the RAM cache size based on the disk cache size; For
every 1GB of disk cache, it uses 1MB of RAM cache (which is really small honestly). I'd definitely
bump this up as much as your box can handle, but make sure to leave room for the connections
and other buffers (setting this is a "trial and error", and is very application specific).
Fwiw, an inactive connection consumes about 32KB of memory, and an active one doubles that
(for additional buffers). SSL connections consumes even more memory. (I think this is an area
where we might be able to improve too, patches are welcomed).

I hope any of this helps your benchmarks (really looking forward to see your results).

-- leif
Message Processed by the MIMEsweeperTM SMTP Appliance

This e-mail and any files transmitted with it are strictly confidential, may be privileged
and are intended only for use by the addressee unless otherwise indicated.  If you are not
the intended recipient any use, dissemination, printing or copying is strictly prohibited
and may be unlawful.  If you have received this e-mail in error, please delete it immediately
and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in
receipt of an email or any errors in its content. Clearswift accepts no responsibility once
an e-mail and any attachments leave us. Unless expressly stated, opinions in this message
are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security

To find out more about Clearswift’s solutions please visit
View raw message