On 03/13/2010 05:17 AM, Craig Andrews wrote:
The memcached plugin uses pecl/memcached which has what I believe to
be some useful features compared to pecl/memcache, one of which is
support for the binary protocol. Such support could be very beneficial
for large sites (such as SN network) because it reduces CPU time spent
and bandwidth used by memcache.
So, from a features POV, memcached is the better plugin. But, more
distros package memcache than memcached (Ubuntu added "d" only in Lucid).
So, I think having both is the best solution for now, until more users
have memcached available in distros.
Also, lib/default.php will auto-select whichever one is available
assuming config.php is using the old (non addPlugin) style memcache
configuration. So, users don't need to be aware that the 2 plugins
even exist.
I dropped that bit out for now to make sure it's not interfering with
our live setup (eg you'll continue to get known behavior if you're using
the old back-compatible setting).
I'm not actually convinced we need two separate plugins here, though...
it might be easier to maintain to use a single plugin, which uses one or
the other backend depending on what's available.
The main problem with the Memcached ("with a d") backend right now is
that we're not 100% sure it's possible to close a connection, which we
need to be able to do for queue processing background threads to keep
them from stomping on each others' data.
For a quick list of the differing features in the backends:
http://code.google.com/p/memcached/wiki/PHPClientComparison
Binary protocol might be a slight efficiency win at scale... atomic
check-and-set might be useful to help ensure consistency. There are some
fancier connection options, which might help failover behavior.
Probably the biggest "serious" change we could make to our memcached
usage would be supporting multi-get (fetching multiple items at once, so
we make fewer network round-trips), which I think we could do with
either backend... however the with-a-d backend also supports explicitly
asynchronous fetches, which could be even more flexible. These are all
kinda tricky to work into our DB_DataObject interface though, so might
be better to wait until after more refactoring of how we work with the
database.
-- brion
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
