Hi Artur, Google groups seems to be a bit fluctuating right now. Trying to post here anyway.
Would you mind giving an example on how you would do it? Do you think that a second instance for this case is a bad practice? Persistent connections is a good idea. Definitely. Thanks a lot for your help! On 24 Maj, 10:41, Artur Ejsmont <[email protected]> wrote: > hi, im not sure if i understand what you mean. > > I am not using this approach myself so im not sure if there is out of the > box solution to your problem. > > If you wish to control caching and distribution etc you would write some > classes to hide the complexity from the rest of the application. Then > implement which ever way you like. > > I guess you would need persistent connections to speed things up. unless you > have too many apache processes and cant afford to keep sockets all the time. > then save data to 2 boxes (if any of saves fails rise alert). On read also > hide complexity reading from any of 2 boxes in pair. If fails rise alert and > try the second one. then you should have even spread of load. > > art > > On 24 May 2010 08:24, Jay <[email protected]> wrote: > > > Hi! That's an option of course. I just had the @operators set now to > > prevent those nasty errors when running Memcached in a non-reliable > > LAN environment. > > Would you make a new instance to do this or makes it sense to use the > > standard instance to save this keys, when utilizing consistent hashing > > on my normal memcache instance? > > > Thanks! > > > On 24 Maj, 02:14, Artur Ejsmont <[email protected]> wrote: > > > i guess you could do it this way - may be slow though as its not > > > asyncronous so has to write to all instances. > > > > No matter what you do using @ operator is a very bad idea. this is how > > > undetectable bugs happen, id check for response and throw exception if > > error > > > is important. > > > > if you have many servers would probably be much more efficient to have > > some > > > kind of consistent hashing function so that each key would be saved into > > 2 > > > servers only. You will not have multiple failures unless you have tons of > > > servers. Then you save each key in 2 servers not N, makes save much much > > > faster and saves you space. > > > > regards > > > > art > > > > On 23 May 2010 23:11, Jay <[email protected]> wrote: > > > > > Hi everyone, > > > > > I have thought a bit on how to make sure that a particular key is > > > > distributed to ALL memcached servers in a pool. I have yet found no > > > > good solution. > > > > > My current, untested solution is to make another instance of > > > > memcached, something like this: > > > > > $cluster['local'] = array('host' => '192.168.1.1', 'port' => > > > > '11211', 'weight' => 50); > > > > > foreach ($this->cluster() as $cluster) { > > > > �...@$this->tempMemcache = new Memcache; > > > > �...@$this->tempMemcache->connect($cluster['host'], > > > > $cluster['port']); > > > > �...@$this->tempMemcache->set($key, $value, $this->compress, > > > > $expireTime); > > > > �...@$this->tempMemcache->close(); > > > > } > > > > > What is common sense to do in this case, when certain keys need to be > > > > stored on ALL servers for reliability?
