We definitely saw this exact same behavior with the PHP PECL module, using consistent hashing. Weirdly enough, I was just digging around before responding, and version 3.0.4 was released a few days ago with the changelog statement: "Improved performance of consistent hash strategy." You might check that out if you're using a version more than a week old, but it sounds like you've decided against consistent hashing. We initially thought it might be a good idea because we're running memcached instances on EC2, but realized even there, the servers are static enough that having additional overhead for each read isn't worth it.
- Marc 2009/2/27 Pavel Aleksandrov <[email protected]> > > I used "naive" for the standard method, because it's described as such > in many places where they talk about this algorithms. As I said in the > previous message, we don't expect the instances to go much up or down, > so using the standard hashing may be OK for what we need. My question > was about the overhead - apparently the module recalculates each time > where everything should go and this involves a lot of hashing for each > server and that translates in CPU load on the web nodes. > > On 27 Фев, 17:08, Brian Moon <[email protected]> wrote: > > On 2/27/09 9:00 AM, Pavel Aleksandrov wrote: > > > > > Never mind the PHP, it's a topic I don't want to discuss :) > > > > > About the changes - the only change that made this impact was changing > > > the hash distribution method. We are currently using the new memcache > > > instances, but with the standard, naive method and there are no > > > negative effects on the load of the web nodes. The moment we switch to > > > the consistent method the load jumps. > > > > Well, I don't use the consistent hashing. I guess I am naive. I also > > have not heard of this problem before however. > > > > -- > > > > Brian. >
