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
