On Jun 27, 9:32 am, Thijs <[email protected]> wrote: > Thanks for this interesting contribution. I'm not totally sure if I > understand the purpose of this though. Libmemcached already does all > the hard work of creating the pool, fail-over, protocol parsing etc. I > can see the advantage of the optimizations that you put into the moxi > such as Multi-get Escalation and Protocol Pipelining, but at the same > time have the fear of adding a new SPOF. I also don't understand how > the L1 cache deals with cache updates. It seems that L1 cache would > only work if you have 1 moxi instance running which would by > definition be a SPOF?
I wouldn't consider it a SPOF any more than libmemcached. I think of it more as the connection mechanism to memached. In practice, it's more like an implementation of spymemcached that works for non-java apps. I think of a JVM as an operating system with threads as processes (this is quite a bit how it's used). spymemcached is a thread that manages communication to upstream memcacheds, does the communication, optimization, etc... for you. L1 cache is a difficult concept, but it's not an automatic thing. It's configured based upon key patterns so you can apply it strategically in your application. IMO, it's most useful for *very* specific applications where you have a small number of very popular items that don't change very frequently. Many applications have a hugely disproportionately hot object such as one that appears on every page for every user. Typically, that goes to a single server and that server ends up saturated. The typical approach for reducing that load is to replicate the object across n servers and be sure to update all of the replicates for consistency, while reading from a random one. This works and provides an invalidation mechanism that isn't *too* complicated (facebook uses their memcached proxy and a reconciliation job to keep these things consistent), but for a very hot object, *not* going over the network is obviously going to be far more efficient. The remaining trick is invalidating it. There are a couple of ways to do such a thing. If your application allows it, the easiest thing is to just set a very short lifetime for objects in the L1 cache. Can you go say, five seconds with an invalid object? One second? How many hits per second per server do you get? The more complicated way to do things is via an invalidation protocol. This is still in a ``we're working on it'' phase. Assuming a small number of keys eligible for L1 and infrequent updates allows us be potentially less efficient with the distribution of invalidations. > Could you explain why you need moxi in your environment? I think moxi > would (only?) be useful in situations where the client currently does > not efficiently manage the connections to the memcached server? For > example if you have a client which does not do persistent connections; > then connecting to a local moxi would be far more efficient because of > the reduced delay for establishing the connection. Yes, there are two really easy big wins: 1) You have a lot of transient processes using cache (as you mentioned above). 2) You want to be able to react quickly to infrastructure changes easily and consistently. In the case of #2, imagine you have a growing server farm with a mix of different applications installed that share a cache. We manage instances centrally based on the application (effectively cache space) in such a way that we can tell all of them to reconfigure dynamically effectively regardless of the number. Imagine performing a controlled memcached server migration without reducing cache hit rates, introducing inconsistencies, or even requiring your application on your 10,000 node server farm to drop their persistent connections. That's a goal, but there are still a couple of items in the way.
