Hi Paul, It seems you have misunderstood a fundamental aspect of memcached. All memcached servers are always equal, there is no master/slave relationship, it is never up to the server to know where a certain key should be stored. It is instead the responsibility of the memcached client to distribute keys among servers, and to do so consistently.
What you are asking for is essentially multi-set, which doesn't need to be implemented in the memcached server, unlike multi-get, but can instead be implemented in the memcached client. Therefore, if you want this functionality, you need to find a client that supports this feature. As Tomash Brechko already pointed out, there is at least one such client for Perl. Given your description of the problem, it also seems rather odd that you would have performance problems with sets? Given that the client has connection pooling, there should be virtually no overhead for doing several large sets serially, as opposed to doing them in bulk as you suggest. The time taken to perform this action should be pretty much proportional to the amount of data you store in memcached. Does your memcached client support connection pooling? /Henrik Schröder On Wed, May 21, 2008 at 10:55 AM, Paul McGrath <[EMAIL PROTECTED]> wrote: > Given the ability to pool memcached daemons - I believe this would require > a small amount of re-architecture of memcached whereby a controlling daemon > was needed to allocate the data to the appropriate memcached node (if > configured in a multi-node manner). > >
