Re: DHR is reporting low

From: Alex Rousskov (
Date: Tue Feb 27 2001 - 22:33:20 MST

On Tue, 27 Feb 2001, Rajesh Agrawal wrote:

> 1. Is there any workload file available to test Reverse proxy.

Sure. There is a WebAxe family of workloads. Please see these URLs for
more info:
> My setup is like this:
> [client]----[router]----(WAN)----[router]------[Server]
> |
> [Proxy]
> 2. Do i need to use ipfw command to introduce a delay, even if i am using
> WAN setup ?

It is up to you: The reason to introduce a delay (and packet loss) is
to simulate a realistic WAN environment. If your existing WAN
environment has appropriate (based on your testing needs) properties,
there is no reason to use Dummynet.

> 3. I used Polygraph 2.4 on freebsd with poly-mix3 workload to test my cache
> engine (Cisco-507). I am getting perfect TPS performance. But, Hit Ratio
> is only 32.53 % however, offered DHR is 57.74%.
> Following errors are reported in the report file. Is there any way to
> improve DHR ?

None of the errors you quoted can affect hit ratio, especially when
there are so few (298) of them.

Why is you cache not serving every hit Polygraph offers? There could
be many reasons, including:

        - The cache is too small to keep the entire working
          set size (plus some headroom). Polygraph reports
          the actual working set size when it gets frozen. Check
          whether the cache can hold at least 125% of the WSS.
          Does DHR loss decrease with time after some plateau
          period, indicating cache running out of space?

        - The cache is too busy and does not have enough
          resources to store (or serve) hits. Compare DHR
          during idle/busy periods of the workload. Study
          cache CPU and disk utilization.

        - Cache's idea of current time differs from Polygraph's
          idea. Make sure all clocks are in sync.

        - Polygraph headers are incompatible with caching
          policies (unlikely if you get at least some hits).
          Check proxy logs.

It is a difficult problem to troubleshoot, especially if several
factors are contributing. It is often useful to look at cache
logs/messages for clues on what going on. You may want to make your
workload as simple as you can to pinpoint the problem. Also, consider
cooperating with Cisco folks that brought Cisco products to the second
cache-off! They may be able to offer cache-specific tips (the above is
pretty generic).



This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:17 MDT