Thanks a lot, Dormando. Will do try to optimize with Ketama first from the client side.
On Thursday, March 21, 2019 at 2:49:59 PM UTC+8, Dormando wrote: > > ketama's just fine. Optimize for problems you have or can prove. > > The default in newer versions is murmur. I keep forgetting that AWS > elasticache is stuck on that old version. Also beware they seem to have > some bugs. If you run into trouble just run your own instances; it's not > too hard. > > On Wed, 20 Mar 2019, Eranda Rajapakshe wrote: > > > Thanks a lot, Dormando! > > I'm using KETAMA_HASH at the client side, didn't go for CRC_HASH as per > the Java Doc it says CRC_HASH can be slower in performance (and > > we are only having Java client, so no need to support for multiple > platforms). We only have max 10 nodes of Memcached, but we want to > > have a fair distribution of values across (at the moment we see 2 nodes > are getting selected in a higher frequency). That's the main > > reason for trying out Murmur3. Is there any default algorithm you can > recommend to solve this issue? > > > > Server-side I will stick for Jenkins for the moment then! Thanks for the > quick response Dormando. > > > > Thanks, > > Eranda > > > > On Thursday, March 21, 2019 at 1:25:13 PM UTC+8, Dormando wrote: > > You don't need to worry about the server one at all. They don't > need to > > match up either; on the server side it's just for the hash table. > The > > default is fine. I only left jenkins in as a "just in case", too. > > > > I don't think it matters that much for clients either. There're > very few > > buckets involved for clients (just the number of servers) so it'd > have to > > be a very poor algorithm to display a significant bias. Most > original > > clients use crc32 and they did fine. > > > > On Wed, 20 Mar 2019, Eranda Rajapakshe wrote: > > > > > Hi, > > > > > > I'm quite an amateur on Memcached, please excuse me if my > understanding is not correct. I'm trying to connect to AWS > > ElastiCache > > > Memcached servers from my Spring service. As per my > understanding cache key hashing is done at two locations.1. client > > side to decide > > > the Memcache node > > > 2. at Memcache node to get the value corresponding to the key > > > > > > For hashing in Memcached server, I found that two possible > algorithms are Jenkins and Murmur. [1] For client-side hashing, > > I see several > > > default algorithms provided in > net.spy.memcached.DefaultHashAlgorithm class. But I cannot see Murmur > algorithm in the Java > > client > > > library as a default algorithm. I'm trying to add Murmur as a > custom implementation and load it to my application. > > > > > > Can you please let me know, whether there is a reason for not > including Murmur in client-side even though its there in the > > Server side. > > > I have read that Murmur3 is a better algorithm to use for > non-crypto hashing but has it proved otherwise for this "node > > selection" > > > scenario. Also please correct me if my understanding is not > correct. > > > > > > [1]. > https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/ParameterGroups.Memcached.html > > > > > > > Thanks, > > > Eranda > > > > > > -- > > > > > > --- > > > You received this message because you are subscribed to the > Google Groups "memcached" group. > > > To unsubscribe from this group and stop receiving emails from > it, send an email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
