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 [mailto:[email protected]] Sent: 14 July 2010 15:38 To: [email protected] Cc: [email protected] Subject: Re: why does cache hit rate tail off? On Jul 14, 2010, at 7:27 AM, Rob Maidment <[email protected]<mailto:[email protected]>> wrote: Hello I’m measuring trafficserver performance using the web polygraph tool: http://www.web-polygraph.org/ 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. Cheers! - Leif regards Rob 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 threats. To find out more about Clearswift’s solutions please visit www.clearswift.com<http://www.clearswift.com> ________________________________ Message Processed by the MIMEsweeperTM SMTP Appliance
