announce: memcached-prefix

52 views
Skip to first unread message

Josh Dybnis

unread,
Apr 14, 2009, 12:10:46 AM4/14/09
to memcached
memcached-prefix is an experimental fork off of the memcached 1.3
development branch. It adds commands pget and pdelete that operate on
ranges of keys having a common prefix. The new commands can be used as
a simple namespace mechanism. It also adds a memcachedb compatible
rget command.

Performance is very close to the standard memcached (see the
benchmarks on the project page). Space usage is also roughly
unchanged.

Project page: http://jdybnis.github.com/memcached/


Mike Panchenko

unread,
Apr 14, 2009, 12:26:37 AM4/14/09
to memc...@googlegroups.com
Interesting... have you tested it with multiple clients? Do you think there's any reason to believe that more clients would cause degradation?

Have you considered making this an option? I'm assuming the most common response to this will be "Memcached works very well for what it was designed. Don't mess with that."

Mike.

Brian Aker

unread,
Apr 14, 2009, 12:44:47 AM4/14/09
to memc...@googlegroups.com
Hi!

Dustin and I were talking about adding this sort of command as an
option to the protocol description for Memcached. If we could come up
with a standard, I would love to add it to libmemcached.

Cheers,
-Brian

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.

Josh Dybnis

unread,
Apr 14, 2009, 1:20:01 AM4/14/09
to memcached
The benchmark numbers on the page were done with 4 client threads. I
did a little testing with more and there wasn't any problem. I didn't
expect that it would given that there were no changes to the
networking code, locking or thread management.

I plan on making memcached-prefix into a plugin engine when pluggable
engine branch is more stable. Right now the new commands are a compile
time option. And it reverts back to using the standard memcached
hashtable if you comment out the line "#define SKIPLIST" in
memcached.h.

-Josh

On Apr 13, 9:26 pm, Mike Panchenko <m...@mihasya.com> wrote:
> Interesting... have you tested it with multiple clients? Do you think
> there's any reason to believe that more clients would cause degradation?
>
> Have you considered making this an option? I'm assuming the most common
> response to this will be "Memcached works very well for what it was
> designed. Don't mess with that."
>
> Mike.
>

Josh Dybnis

unread,
Apr 14, 2009, 1:38:13 AM4/14/09
to memcached
Basically whatever you guys make standard I'll put into the branch.

The pget and pdelete were just the simplest thing I could come up with
that would do the job. What do you think?

The rget command I copied from memcachedb. The only thing I don't like
about it is that I think the end key should be optional so that you
don't have to specify a maximal key if you want to iterate through the
whole cache.

-Josh

On Apr 13, 9:44 pm, Brian Aker <br...@tangent.org> wrote:
> Hi!
>
> Dustin and I were talking about adding this sort of command as an  
> option to the protocol description for Memcached. If we could come up  
> with a standard, I would love to add it to libmemcached.
>
> Cheers,
>         -Brian
>
> On Apr 13, 2009, at 9:26 PM, Mike Panchenko wrote:
>
>
>
> > Interesting... have you tested it with multiple clients? Do you  
> > think there's any reason to believe that more clients would cause  
> > degradation?
>
> > Have you considered making this an option? I'm assuming the most  
> > common response to this will be "Memcached works very well for what  
> > it was designed. Don't mess with that."
>
> > Mike.
>
> > On Mon, Apr 13, 2009 at 9:10 PM, Josh Dybnis <jdyb...@gmail.com>  
> > wrote:
>
> > memcached-prefix is an experimental fork off of the memcached 1.3
> > development branch. It adds commands pget and pdelete that operate on
> > ranges of keys having a common prefix. The new commands can be used as
> > a simple namespace mechanism. It also adds a memcachedb compatible
> > rget command.
>
> > Performance is very close to the standard memcached (see the
> > benchmarks on the project page). Space usage is also roughly
> > unchanged.
>
> > Project page:http://jdybnis.github.com/memcached/
>
> --
> _______________________________________________________
> Brian "Krow" Aker, brian at tangent.org
> Seattle, Washingtonhttp://krow.net/                    <-- Mehttp://tangent.org/               <-- Software

Mike Panchenko

unread,
Apr 14, 2009, 12:44:43 PM4/14/09
to memc...@googlegroups.com
That is what I figured you'd say, just wanted to make sure.

In that case, very nice! :)

Mike.

Jay Paroline

unread,
Apr 14, 2009, 10:34:40 PM4/14/09
to memcached
This is a cool idea, but I wonder how useful it is when running a
large number of memcached servers. Presumably one would have to
connect to each one and send the pget or pdelete commands?

I currently achieve the pdelete effect in code by using a predefined
prefix and then "abandoning" the keys when they need to be deleted
simply by having the prefix change.

i.e. 123:getUser:10 becomes 124:getUser:10. Technically the data for
123:getUser:10 is still in memcache, but nothing will ever read it and
it will eventually get flushed out.

I don't know of any easy way to do something like pget in a client,
and I can think of a couple instances where it would be useful, but it
would also be incredibly easy to end up requesting way too much data,
and again with having to connect to each memcached server, it might
still be more hassle than it's worth.

Jay
Reply all
Reply to author
Forward
0 new messages