Duane Wessels <wessels@nlanr.net> writes:
> [ sha compression bit deleted ]
> Anyway, Kostas is working on adding hit metering into Squid and today
> we realized that hit metering will become very difficult when the
> cache key is one-way hash of the URL. When we need to purge
> an object, we're supposed to make a HEAD request for the URL to
> report the hits. But we won't have the URL any more.
>
> In fact, hit metering will require quite a bit of additional overhead
> for every object. In addition to some four integer counters, the draft
> requires that hits be reported back to the source of the object, and
> not necessarily the origin server. So we'd have to remember which
> neighbor gave us each object. ick.
>
> Thoughts?
Maintain a seperate dbm/ndbm/gdbm/whatever database for SHA --> URL
mappings? Only enabled if hit metering is enabled, and updated via a
helper?
After all, AFAIK the hit metering doesn't need to be in realtime to
there's no point in holding all the data in ram...
Then when you delete, you sent a delete request to the helper, and it
fires off the HEAD request after looking up the database for the URL,
at which point it deletes the entry.
This works for me, but then I don't think hit metering is very
important. :)
Received on Tue Jul 29 2003 - 13:15:44 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:29 MST