Hi!
For a geographical cache the proxy makes sence because latency for the
proxy is less then that of the wan.
In house? The l1 could be significant (this is part of the reason I am
doing the embedded work in libmemcached).
Cheers,
--Brian
On Jun 27, 2009, at 11:17 AM, Michael Shadle <[email protected]> wrote:
I hate to say it but I think the words that came out of Brian or
Eric's mouth were something like "... so you don't need something like
a proxy ..." when describing either gearman or memcached (and both are
conceptually the same from a scaling methodology)
There may be a usage model for this but it is fundamentally against
the point of the application's shared-nothing design. I will say
though that protocol conversion and some other things might be
interesting and useful but treating it like a traditional proxy is
basically against the point.
However, if each memcached client has its own moxi client, moxi must
have its own hashing algorithm then etc. I am wondering though how
much of the L1 cache functionality could be pushed to the application
layer instead of a middle-man to the memcached servers?
Calling this a proxy initially threw me off, reading the post a little
further it -is- a proxy but "proxy" makes people think what I
initially thought - something like MySQL proxy, etc...
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
