On Aug 21, 6:10 pm, Bill Moseley <[email protected]> wrote:
> I've often seen comments about using multi-gets for better performance.
> First, I'm a bit curious if/why it's a big performance gain.
> Obviously, not all keys will be on the same memcached server in a multi-get
> request. Can somoene give me the one short explanaition or point me to
> where to learn more?
>
Because asking for values can be asynchronous, I guess.
So for more than one key, can do a lot of waiting for responses in
parallel, rather than waiting for each key.
Request key1
Request key2
Wait for key1 and key2 response
Request key1
Wait for key1 response
Request key2
Wait for key2 response
>
> I'm perhaps more curious how people use multiple gets -- or really the
> design of an web application that supports this.
>
> I've tended to cache at a pretty low level -- that is if I have a method in
> the data model to fetch object "foo" I tend to check the cache, if not found
> then fetch from the database and save to memcached. As a result we can end
> up with a lot of separate memcached get requests for a single web-request.
> This is less true as the app becomes more web2.0-ish, but still happens.
>
> So, I'm curious about the design of an application that supports gathering
> up a number of (perhaps unrelated) cache requests and fetch all at once.
> Then fill in the cache where there are cache-misses. Am I misunderstanding
> how people use this feature?
Currently experimenting with putting tree structures into memcached
using multi-gets to retrieve all the nodes at a particular depth. So
if the height of the tree is N, only need N multi-gets, assuming the
whole tree is in memcached.
Nodes are HTML fragments complete with caching data, and a node's
children are its includes/dependencies.
There is a bit more to it than that, as can have varying HTML
fragments, which might need N+1 multi-gets, and toying with the idea
of using a hierarchy of caches, and using a process level cache (APC)
to cache the root nodes.
Jared
