Re: New document on "Simple hit-metering for HTTP"

    I thought up another fix some hours after I sent my message: adopt the
    rule that a server which is only relaying, not generating, a response
    must not count it.  In the above example, the origin server itself
    would count the hit, not any upstream proxy cache.
    
    This way, when serving a request the origin server can immediately add
    1 to its total hit count.  With my earlier fix, it would have to wait
    for proxy 2 to report the hit in a future request.

This sounds reasonable, although I want to spend some time working
out all of the cases before I'm sure.  It's also important to optimize
the "1-hit" case, since various cache studies have shown that most
URLs (even the cachable ones) are not re-referenced before being
deleted from the proxy cache.  I.e., we want this mechanism to work
in such a way that if a proxy only uses an entity once, then there
are no extra messages sent.

So, for example, the sentence that says:
  When a proxy first caches R, it should set U to 1.
might have to be changed to
  When a proxy first caches R, it should set U to 0.
and then the examples would also need to be changed.

    I'm primarily worried about the filesystem read/write overhead needed
    to maintain the counters.  I would like to hear an implementer say
    that this is not a problem.

We say several times that this is a "best-efforts" mechanism.  I think
at one point we discussed explicitly stating that a proxy does NOT
have to keep the counts in non-volatile (crash-proof) storage.
Unless your proxy crashes frequently (which would make it rather
unattractive in the first place), there is no reason to require
a file-system write to update a counter.  Certainly, it need not
be a synchronous write.  (If asynchronous writes were such a problem,
proxies wouldn't keep multiple log files the way they do now.)

-Jeff

Received on Wednesday, 7 August 1996 16:21:37 UTC