Didier; What you've suggested is one approach to software/system architecture, but it does have a drawback. Namely, if at any point there is a problem with moxi, you've pushed your application logic to it, so you're "dead in the water" if it breaks or goes down. With memcached, the point is it is there to speed things up and a failure of it at any point still leaves you functional (although potentially degraded due to scalability constraints) due to the fact that it is the cache, not the primary data store. Keep that in mind if you choose to pursue the approach of pushing application logic to a cache or proxy rather than keeping it in your application itself.
/tmy On Sat, Jun 27, 2009 at 6:31 AM, Didier <[email protected]> wrote: > > 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 >
