Server Selection

Greg Whalin gwhalin at meetup.com
Tue Dec 6 14:44:57 UTC 2005


Richard Thomas wrote:
> Last server on the list might be a failover, Not as much memory as the 
> main server but better then nothing at all..


Simply by being in the list, it would have an equal chance (assuming all 
weights are equal) of being picked, so would not really be a failover. 
Even using weighting, it would not be a failover, just less likely to be 
picked.  We actually do this in our production cluster.  We have 3 
servers: 2 w/ 3 GB of ram and 1 w/ 2, so we use weighting to distribute 
accordingly.


> I think its just a moot point anyway, Its 100% manageable by the person 
> setting up the connections, just list the connections in order and your 
> good to go. Why do a internal sort when the user can sort it themselves, 
> leaves them in total control.
> 
> Maybe a option to sort by I sure wouldn't want it a default.

Agreed 100%.

gw



> 
> 
> Richard Thomas - CEO
> Cyberlot Technologies Group Inc.
> 507.398.4124 - Voice
> 
> 
> Greg Whalin wrote:
> 
>> Ivan Krstic wrote:
>>
>>> Lee Kemp wrote:
>>>
>>>> Yeah, so say if i had one webserver that has
>>>> [...]
>>>> set as there memcached server ips, will this cause issue with  
>>>> duplicate
>>>> items in my cache etc..? or would the hash still work out ok?
>>>
>>>
>>>
>>>
>>> This is solely dependent on the client implementation. You mentioned you
>>> were using the Java API, and from my one-minute glance at its source, it
>>>  looks like servers are internally placed into buckets in the order
>>> given at instantiation, and the cache key's CRC is transformed directly
>>> to a bucket array index, so you can't have servers listed in different
>>> orders in your clients if you don't want useless copies of the 
>>> information.
>>>
>>> This should be easily solved by patching SockIOPool to sort the given
>>> server list before transforming it to a bucket array. If any of your
>>> clients has a server list whose length differs from any other's,
>>> however, you're bound to get unnecessary duplication, and there's no
>>> easy way around that.
>>>
>>> Greg Whalin, the JAVA memcached API author, is on the list, so he'll
>>> correct me if I misread his code.
>>
>>
>>
>> This is 100% correct.  I guess I had never envisioned people putting 
>> the order in different.  I would not feel comfortable re-sorting the 
>> list in the event that the user intentionally set the order for some 
>> reason (can't think of a very compelling one off the top of my head, 
>> but does not mean there is not one).
>>
>> gw



More information about the memcached mailing list