tag proposal

[Dustin Sallings]

On Oct 4, 2007, at 9:11 , Steven Grimm wrote:

> Tobias Lütke wrote:
>> This also means that the number of tags in the system will be quite
>> large. There will be one or more tags for each row in the articles
>> table. I expect the amount of tags to be vastly larger then the  
>> amount
>> of keys in future memcached servers.
>
> Which is why I'm kind of skeptical about the whole tags thing,  
> honestly. It seems like an optimization for the rare case  
> (invalidation) at the expense of the vastly more common case  
> (getting values by ID) by virtue of reducing the amount of memory  
> available for keys and values. Fewer items in the cache equals  
> lower hit rate.

	There are only a large number of tags if you create a large number  
of tags.

> Obviously different applications have different usage. I can tell  
> you that in our application, gets outnumber deletes by at least two  
> orders of magnitude across the board, and many of our objects are  
> so small that any tag would likely eat more memory than the value  
> being cached. (Not, perhaps, than the object header, but certainly  
> more than the value.)

	I would hope that it'd generally be the case that deletes aren't  
common.  I'm hoping that tags aren't going to encourage people to  
delete *more*, but to delete more accurately.

> Also, invalidating a tag means broadcasting a "delete by tag"  
> request to all the memcached servers since you have no way of  
> knowing which servers have objects with which tags. For large sites  
> with lots of memcached servers, or even medium-sized sites using  
> the "run a memcached instance on each web host" approach, that  
> means a ton of outgoing requests, almost all of which are likely to  
> not invalidate anything at all if the tags are relatively sparse.

	It's a lot of requests rarely.  Broadcast isn't particularly  
expensive in my client, but I certainly can see how it is for others.

	It comes down to measurements, I suppose.  If tags help, then it'll  
be useful.

> Not saying the feature isn't worth adding; there are doubtless  
> valid use cases for it. But whatever implementation finally  
> arrives, IMO, shouldn't impose any per-object memory overhead on  
> objects that have no tags at all. Or if it does, it should be  
> surrounded by #ifdef so that sites that don't need it don't see  
> their available cache memory drop substantially when they upgrade.

	I was imagining the overhead being something like 8 bytes per item  
on a 32-bit system as well as the tag hash table.

-- 
Dustin Sallings