Better server selection client code?
Jed Reynolds
lists at benrey.is-a-geek.net
Fri Oct 20 09:17:14 UTC 2006
Jeetendra Mirchandani wrote:
> On 10/19/06, Andrew Harbick <aharbick at aharbick.com> wrote:
>> > But here you can have a problem of load distribution. According to the
>> > algorithm, if 2 servers map to points very close on the unit
>> circle, the
>> > load distribution will be screwed badly.
>> >
>> > possible solution - dont use hashing for mapping servers to the unit
>> > circle, instead maintain a map, and pick the longest arc to place the
>> > new server.
>>
>> Agreed. But I don't think it has to be that fancy. I just position the
>> servers around the unit circle at even intervals.
>
> But when I add a new server, I dont want to move all the servers to
> maintain the intervals same. That is same as doing a modulo function.
I've gotta stop coding and read this article. But...I was thinking about
this from a practical standpoint today. The degree of complexity of
managing cache mapping could become a bottleneck to regular maintenance
if it was something coded on each client machine (aka, not a real
management solution).
However, if I never aim for a perfect cache hit rate to begin with, I
can move servers in and out of the cache group so long as I already have
buckets to cover where they were and where they are. If I plan on adding
some servers, I will add the server to bucket positions that I've left
unfilled and are current registering as cache-misses. Same thing for
reboots or maintenance...just leave the bucket empty and assume higher
cache misses and database load. This is only feasible if you have plenty
of cache servers and the length of timeout on a cache miss is really
short. So if you have two memcache servers, and one goes down, then
that's likely going to cause undo load. But if you have 10, you're more
likely to tolerate the higher resulting database load from corresponding
cache misses. However, this stragegy makes it difficult to widely grow
the number of caches because you'd have to assume a wildly high cache
miss rate to begin with. If you were to double the number of caches,
you'd have to have a really bad cache miss rate to begin with to fit it
into existing bucket mapping.
Jed
More information about the memcached
mailing list