All, I have memcached running on two boxes and memcache-client installed and am ready to integrate into my Rails app. I see lots of references to running the memcached server daemon process on several servers. This implies that you would have completely different caches on each machine, correct? So you would just fire up as many cache processes as you need to cache different items in hopes of distributing the load. There isn''t any notion of some sort of distributed cache (cache that lives on multiple servers), right? That would seem to imply some sort of replication or cache server affinity. Thanks, Wes -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Philip Hallstrom
2007-Mar-05 17:27 UTC
Re: Question about running memcached on multiple servers
> I have memcached running on two boxes and memcache-client installed and > am ready to integrate into my Rails app. > > I see lots of references to running the memcached server daemon process > on several servers. This implies that you would have completely > different caches on each machine, correct? So you would just fire up as > many cache processes as you need to cache different items in hopes of > distributing the load. > > There isn''t any notion of some sort of distributed cache (cache that > lives on multiple servers), right? That would seem to imply some sort > of replication or cache server affinity.Right... from the memcache page... ------------- Now, what actually happens is that the API hashes your key to a unique server. (You define all the available servers and their weightings when initializing the API) Alternatively, the APIs also let you provide your own hash value. A good hash value for user-related data is the user''s ID number. Then, the API maps that hash value onto a server (modulus number of server buckets, one bucket for each server IP/port, but some can be weighted heigher if they have more memory available). If a host goes down, the API re-maps that dead host''s requests onto the servers that are available. ------------- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Very nice. So it really is a distributed cache out of the box. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---