Patch: CPU efficiency, UDP support, and other changes

[Stephen Woodbridge]

OK, well while your at it, you need to deal with the 1 MB item memory 
limit. One way to do this would be to have the set/put/append/etc 
methods return the size of the object as stored in memcached.

-Steve

Paul T wrote:
> Memcached is (a bit) more than 'just' a hash table.
> 
> For example - memcached has 'increment' / 'decrement'.
> 
> Now if only memcached would get built-in append(key,
> string) (which would *append* the string to current
> value of the key - kind of similiar to increment only
> for strings) so - if memcahed would get a built-in
> 'append' then it would be easy to implement the
> desired cascading functionality as an external layer,
> using  mamecached *itself* for storing the list of
> dependencies.
> 
> The pseudocode will be something like this:
> 
> CascacdingPut( key, value, logical_group ) {
>    m->set( key, value );
>    m->append( "_group:" + logical_group, key ); 
> }
> 
> CascadingDropGroup( logical_group ) {
> 
>    $list_of_keys_as_string 
>         = m->get( "_group:" + logical_group );
> 
>    @list_of_keys = split $list_of_keys_as_string;
> 
>    foreach key in @list_of_keys {
>         m->delete( key );
>    }
> 
>    m->delete( "_group:" + logical_group );
> }
> 
> I would vote for adding 'append' to the core - keeps
> the architecture consistent yet opens the door for all
> those 'cascading' things (or whatever else the
> application layer would demand).
> 
> Rgds.Paul.
> 
> --- David Ulevitch <davidu at everydns.net> wrote:
> 
> 
>>Memcached is a hash table for all the pros and cons
>>that come with  
>>being a hash table.
>>
>>I can't imagine support for this.  Try a SQL cache
>>or an Object  
>>Persistence database.
>>
>>-david
>>
>>On May 4, 2006, at 5:15 PM, Cahill, Earl wrote:
>>
>>
>>>Well, went through this recently in the 'namespace
>>
>>bids' thread.   
>>
>>>Really
>>>I want to be able to clear a set of arbitrarily
>>
>>associated keys,  
>>
>>>all at
>>>the same time.  Kind of like an on delete
>>
>>cascade-ish thing.
>>
>>>Like have any number of keys associated with a
>>
>>user, and then if the
>>
>>>user makes a change, wipe all his keys, so that
>>
>>the user gets fresh
>>
>>>stuff on his next hit.  But to be able to do it
>>
>>without keeping  
>>
>>>track of
>>>all the keys associated with the user.  And to
>>
>>have the namespaces  
>>
>>>scale
>>>to about the level of keys now.  Then if we have
>>
>>millions of users, it
>>
>>>just works as nicely as memcached does now.  I
>>
>>would envision all the
>>
>>>keys for a given namespace to reside on the same
>>
>>server, which I think
>>
>>>could simplify things.
>>>
>>>Also (and please no one go nuts on me), I would
>>
>>like to build a
>>
>>>row-level query cache that could work with foreign
>>
>>keys, and  
>>
>>>namespaces
>>>I think could help with that.
>>>
>>>Earl
>>>
>>>
>>>>-----Original Message-----
>>>>From: Steven Grimm [mailto:sgrimm at facebook.com]
>>>>Sent: Thursday, May 04, 2006 4:17 PM
>>>>To: Cahill, Earl
>>>>Cc: memcached at lists.danga.com
>>>>Subject: Re: Patch: CPU efficiency, UDP support,
>>
>>and other changes
>>
>>>>Cahill, Earl wrote:
>>>>
>>>>>Now if you could just add some real namespace
>>
>>support . . . .
>>
>>>Wouldn't
>>>
>>>>>facebook be interested in such a thing?
>>>>>
>>>>
>>>>Depends on what you mean by namespace support. We
>>
>>partition our keys
>>
>>>to
>>>
>>>>different sets of servers based on prefixes (all
>>
>>the keys that start
>>
>>>>with "xyz" go to one pool of servers and all the
>>
>>"abc" keys go to a
>>
>>>>different pool) but that's purely a client-side
>>
>>change. The memcached
>>
>>>>servers have no idea what keys they're going to
>>
>>be asked to deal  
>>
>>>>with.
>>>>The motivation for partitioning the key space was
>>
>>mostly to cut down
>>
>>>on
>>>
>>>>network traffic for multi-key "get" requests,
>>
>>though it has other
>>
>>>>benefits as well.
>>>>
>>>>What did you have in mind that would require
>>
>>server support?
>>
>>>>-Steve
>>
>>
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>