That is what I figured you'd say, just wanted to make sure. In that case, very nice! :)
Mike. On Mon, Apr 13, 2009 at 10:20 PM, Josh Dybnis <jdyb...@gmail.com> wrote: > > 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. > > > > 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/ >
