some questions that weren't FAQs

[Brad Fitzpatrick]

We do both:  we have machines with 512 MB, 1GB, 3GB, and 10 GB.  Wherever
we have space.... doesn't really matter as far as memcache is concerned.


On Wed, 26 Nov 2003, Justin Matlock wrote:

> A little off topic...
>
> Brad... in practice, have you found it better to have lots of small
> memcache's (like a 1gb one on each webserver), or two or three
> "megacaches" (having multiple caches, using the max 4gb)?  You guys at
> LJ are the only ones I know that have enough hardware -- and enough data
> --  to have tried it both ways. :)
>
> On a different note -- is anyone still seeing that funky problem where a
> memcached gets in a whacked out state, and starts chewing 100% CPU, or
> did that get fixed, and I just missed it?
>
> J
>
> >That's a very real possibility.  The idea is that your application is
> >tolerant of the cache being wrong by doing things like making big,
> >expensive objects stay in the cache forever, but making them dependent on
> >smaller objects which are quicker to revalidate, and have those expire.
> >
> >However, we also provide a way to turn that off (at least in the latest
> >CVS version), you can set $args->{'no_rehash'} when you construct your
> >memcached client object, then the re-mapping behavior is disabled.  Note
> >that this is only in the Perl client currently, as far as I'm aware.
> >
> >- Brad
> >
> >
> >On Wed, 26 Nov 2003, Larry Leszczynski wrote:
> >
> >
> >
> >>Hi Evan -
> >>
> >>
> >>
> >>>>1) It looks like the client initializes with a list of servers it knows
> >>>>about, how do those servers communicate with each other (assuming they do)
> >>>>so they stay consistent with each other?
> >>>>
> >>>>
> >>>Servers are independent.  A given key is stored on only one server, and
> >>>which server a key lives on is decided by the client-side memcache
> >>>library code.
> >>>
> >>>
> >>Got it, thanks.  I saw this line:
> >>
> >>	If a host goes down, the API re-maps that dead host's requests
> >>	onto the servers that are available.
> >>
> >>so I was assuming that there was some sort of failover between servers
> >>going on.
> >>
> >>This all looks very slick, I can definitely see places where I could put
> >>it to good use.  But I'm wondering: since servers don't share data,
> >>doesn't this cause runtime inconsistency problems?  Like if I have two
> >>boxes that each run my web app plus memcached, and I configure each web
> >>app to know about both of the memcached instances:
> >>
> >>   - Some request from user 1234 hits box A
> >>   - Web app on A stores some data in the cache with a key "foo:1234"
> >>   - The client on box A hashes this to either memcache A or memcache B
> >>     (suppose it picks memcache B)
> >>   - A later request from user 1234 hits box B
> >>   - Web app on B looks up data with key "foo:1234"
> >>   - The client on box B hashes this to either memcache A or memcache B
> >>     (should look for the data in memcache B)
> >>
> >>But say there's a network glitch or something and the client on box A
> >>thinks the server on box B is dead because it can't be reached.  So cache
> >>lookups on box A for "foo:1234" will now go to server A, but lookups on
> >>box B will still go to server B, won't they?  Does the client on box A
> >>periodically check to see if server B has come back?
> >>
> >>
> >>Thanks!
> >>Larry Leszczynski
> >>larryl@furph.com
> >>
> >>
> >>
> >>
> >>
>
>