Hi, I didn't know about this project, and I'm delighted to discover it. IMO, it has a lot of potential, and may end up in the toolbox of any memcached user ...
In the example use case you have just described, I don't really understand how the L1 cache works though. If you consider a number of web server boxes, and you install moxi on each of them, so they can be reached by processes and scripts using a loopback connection, then you will have one local cache per box. How is it possible to guarantee the consistency between these caches? How does moxi know the values it keeps in its local cache are up-to-date? One solution would be to run one moxi instance on a middle box to centralize all memcached accesses, but it would become a single point of failure in the architecture. It does not sound very consistent with the general memcached philosophy regarding high-availability ... IMO, the killer feature of moxi is the aggregation of concurrent GET requests (a la spymemcached), since it can both reduce the number of connections on a memcached farms, and also optimize the network by avoiding a flood of small communication packets. What I would like to see in the future is a support of plugins or extensions, so that developers can code their own cache management logic in the proxy itself. I'm not talking about a L1 cache, but rather migrating the logic which is typically implemented on client side to the proxy. For instance, a typical client may try to access memcached to retrieve a key; if there is no result, it will access any stable storage medium, and then store the result back in memcached before performing its own work. This logic could be moved in moxi, provided the developer can provide the code to access the stable storage medium. Since accesses to stable storage are often synchronous operations (i.e. think about a RDBMS for instance), they would have to be done in a separate pool of threads, in order to avoid blocking the moxi communication threads. Of course, such implementation is not trivial and will probably require a careful design to synchronize all those threads ... The main benefit I could see is the proxy would optimize not only the roundtrips to a memcached farm, but also the roundtrips to the underlying storage mechanism (which are much more expensive than the ones to memcached), both in term of number of connections and packet aggregation. At the company I work for, I can see at least two different projects which would benefit of such a feature ... Apologies for the longish post, it is a very interesting topic ... Best regards, Didier. On Jun 27, 4:25 am, "steve.yen" <[email protected]> wrote: > Hi! > > I saw some talk about memcached proxies on the list today, so figured > it'd be good to let you all know about "moxi", a new open-source > memcached proxy. Dustin Sallings, Matt Ingenthron and I have been > working on it, where moxi fits together the latest memcached (1.4) and > libmemcached projects. License is BSD, and more info's at... > > http://labs.northscale.com/moxi > > We needed something that spoke memcached binary protocol, initially on > the proxy-to-memcached side of things, and wanted something that could > be kept up to date with the latest memcached + libmemcached features. > > The idea with moxi is that webapp processes and scripts connect to it > running at localhost:11211. Then, moxi multiplexes traffic to a pool > of memcached servers. > > On compatibility, moxi passes the same test suite as memcached, except > for the ones that don't make sense for a proxy, eg testing "dash-M" > command-line flags. There are also new test cases to exercise > proxy-only features and topologies. > > moxi also supports protocol conversions, so webapp processes and > scripts can still speak ascii protocol, while moxi can optionally use > binary protocol to speak to memcached servers. > > One possibly useful optimization: moxi has a configurable front cache, > so it can keep a small number of hot items in moxi's memory, saving on > wire network hops. In other words, an L1 cache. > > Another optimization, moxi can de-deplicate concurrent GET requests > for popular keys, based on ideas from Dustin Sallings' spymemcached > client. See:http://code.google.com/p/spymemcached/wiki/Optimizations > > There are more features and ideas in plan, but they're more > work-in-progress. Appreciate any feedback, share what you want to > see, not see, etc. > > Cheers, > Steve
