my ditto. i'd sugest a one-shot swich, make full test on your new memached api wrapper before that of coz. with a consistent hashing algo integrated, pecl/memcached brings much better experience along.
i've tried to make a switch of same kind on 100+GB cache data months ago. no worry, take it easy. if you can tolerate a little bit data inconsistency for a short while, that would be even faster. On Wed, Feb 3, 2010 at 12:18 PM, nEosAg <[email protected]> wrote: > hey jay, > > we both are sailing in same boat!! I am in process of shifting from > pecl/memcache to pecl/memcached too. I have done some testing > yesterday itself, and have some feedback which might help you. > > First of all, look very seriously and carefully which hashing policy > you were using(with memcache) and which one you have used(memcached) > currently dusring you testing. > Memcache uses Traditional hashing policy i.e. Modula(depends upon no. > of servers) by default and it also supports *consistent* hashing > policy. > > So, it was *only* coincidence that you get key from memcached which > was set by memcache, that means key was mapped to same server. > > So as far as both the libraris uses same Hashing Policy you will get > same result, ideally (but i doubt as both libraries have their > implementation for Hashing Algorithms), But if you have used diff > Hashing policies in both clients then you CANT get same results. > > Secondly, i would recommend don't use both the clients together, do > your full fledged testing with memcached on ur test servers and then > if satisfied make another wrapper class and use it. Beware, you cant > avoid a Memcache Server Restart in this case, as your keys will be > remapped, its better to FLUSH ALL and Warm the Cache again, i can > understand the pain it may cause as im having only 2GB of data still > thinking of Gracefull way to do it. > > > On Feb 3, 6:07 am, Jay Paroline <[email protected]> wrote: > > Fortunately, way back when we started using memcache I wrote a wrapper > > for it to handle some of the more tedious stuff for me automatically. > > All our code uses that wrapper class, so I just had to change the one > > class to swap out extensions. :) > > > > Unfortunately in our testing we are seeing some weirdness. If we set a > > key from pecl/memcache we can get it from pecl/memcached, but if we > > set it from pecl/memcached, we can't retrieve it from pecl/memcache. I > > was hoping that I just missed something in the long list of options > > that would make it fully backwards compatible. > > > > Jay > > > > On Feb 2, 10:34 am, Brian Moon <[email protected]> wrote: > > > > > The syntax differences don't lend themselves to being swapped out that > > > easily. Unless you are going to do a full code roll out to one set of > > > servers and not another, I don't think this is too easy. > > > > > They have different compression settings and I am not sure if they set > > > the same flag when sending compressed data. I have not had a reason to > > > look into it. > > > > > A simple test would tell you for sure. Just try it out on your test > > > systems and see how it works. Report back. > > > > > Brian. > > > --------http://brian.moonspot.net/ > > > > > On 2/1/10 11:51 PM, Jay Paroline wrote: > > > > > > Hi all, > > > > > > We're in the process of switching from the pecl memcache extension to > > > > the pecl memcached extension, but we would like to start out by doing > > > > a very limited rollout of the memcached extension so we can compare > > > > performance and make sure everything is working as expected. > > > > The documentation about the hashing/failover strategies used by the > > > > memcache extension is extremely limited. Does anyone know which > > > > settings I should use for so that pecl/memcache and pecl/memcached > > > > choose the same servers for each key? Should it be considered > > > > generally safe to have both clients working on the same keys? > > > > > > Thanks, > > > > > > Jay >
