On Jul 14, 2010, at 7:27 AM, Rob Maidment <[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
