Client interoperability, server selection.

[Tomash Brechko]

On Tue, Mar 11, 2008 at 11:47:12 -0700, Josh Snyder wrote:
> One more to add -- the consistent hashing is not quite perfect, in
> that adding/removing a server causes some unrelated items to get
> rehashed to different servers. There's a (too) long email about this,
> including tests and an explanation of why it happens, at:
> 
> http://lists.danga.com/pipermail/memcached/2007-October/005588.html
> 
> See also Richard Jones' recent comments at
> 
> http://lists.danga.com/pipermail/memcached/2008-March/006551.html
> 
> It is not a critical problem (in an out-of-the-box test, only between
> 5% and 10% of items get rehashed unnecessarily), but if we're shooting
> for a standard, it might be worth trying to resolve.

Thanks for reminding this.  I didn't look that deep myself.  Indeed,
there seem to be no need to change the number of points of remaining
servers.  Actually, implementation in Cache::Memcached::Fast uses
fixed <ketama_points> * <server_weight> irrespectively of the number
of other servers and their weights, and I kinda assumed everyone does
the same.

So, can we all agree on fixed (user controllable) number of points per
server, or are there any reasons to do the dynamic scaling?  As I
understand it, server weight is there to reflect how many memory
and/or bandwidth a particular server has, and this doesn't change with
other machines go up and down.


-- 
   Tomash Brechko