On Fri, 6 Aug 1999, Jose Sua (Exchange) wrote:
> in the real world when a client receives data that he thinks is stale, he
> hits the refresh button.
True, and we can simulate that. IMO, it is still interesting to see how
many stale objects are returned depending on the proxy in use. Again, we
will distinguish between stale objects that require guess work from
those that should never be returned stale.
> I thinks that the important measure here is (3), meaning that the cache has
> a problem handling the expire times.
I agree. It does not hurt to measure more than (3) though since we have
to simulate those anyway.
> for (2) most caches have a default setting depending on the site. A
> preference of freshens over saving bandwidth, so its a configuration issue.
Sure, so we will see how configurable with respect to this trade-off
each proxy is, and also what trade-off level a vendor has chosen for
PolyMix-2. There are many similar trade-offs that we are already
testing. For example, hit ratio versus throughput ("healing" and
"bypass" modes of all kinds).
> for (1) what does it measure ? this is more a design of website issue,
> establishing correct expire times.
In most cases, Web sites cannot know exact expiration times so they have
to lie (and we have to simulate that).
The measurements will show how well a proxy handles case (i). If all
proxies handle case (i) equally well/bad, there will be nothing to talk
about. Otherwise, we can discuss the differences for that particular
test.
Once again, case (3) is the only case when we can report an "erroneous"
behavior on proxy part. Other cases are not errors.
> On Fri, 6 Aug 1999, Ron Lee wrote:
>
> When you say "Polygraph will report the number of "stale" objects
> served by the cache" do you mean: (1) the cache was given an
> expiration header and the origin server changed the content before it
> expired, thus the cache unknowingly served stale content, (2) the
> cache was NOT given an expiration header, relied on its own default
> expiration policy, the origin server changed the content before the
> cache's copy expired, thus the cache unknowingly served stale content,
> or (3) the cache was given a valid expiration header and the cache
> knowingly served stale content after expiration?
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:08 MDT