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:02:28 GMT

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?

From: Leif Hedstrom []
Sent: 14 July 2010 15:38
Subject: Re: why does cache hit rate tail off?

On Jul 14, 2010, at 7:27 AM, Rob Maidment <<>>

I’m measuring trafficserver performance using the web polygraph tool:

Performance is generally impressive, but I’m trying to understand the strange results I’m
seeing for cache hit rate.  The test is a short duration (20 minutes) and initially the hit
rate measured by polygraph exactly matches the expected (offered) rate.  However 3 minutes
into the test the hit rate starts to drop below the expected rate and continues to tail off
for the duration of the test.  Can anyone explain why this might be?

That doesn't sound good. Is the cache churning by chance? How large is the RAM cache and disk
cache?  Is there significant disk I/O or contention on the disks?

I’m testing on a 1 Gbps network – does trafficserver somehow work out it’s quicker to
get responses from the server than from its local cache??  Is this tuneable at all?

No. But there are algorithms for promoting and evicting object from disk cache to RAM cache,
for evicting out of RAM cache, and of course for evicting out of disk cache. The default RAM
cache eviction algorithm was recently changed, maybe you can try the old (LRU) policy as well?

One other thing to look for is to make sure the traffic_server process isn't crashing / restarting.
This might happen fairly transparently, but would increase cache misses, since while restarting
and initializing the caches, ATS will forward every request to the backend. If the restarts
happens frequent it might not even get a chance to sync the directories to disk.


- Leif


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<>

Message Processed by the MIMEsweeperTM SMTP Appliance
View raw message