3 ms·
This would help to distribute requests for individual objects, but doesn't help for multi-get requests. The problem is adding more nodes increases the number o
by sstrudeau 17y ago
This would help to distribute requests for individual objects, but doesn't help for multi-get requests. The problem is adding more nodes increases the number of actual requests a multi-get call needs to make (assuming you're asking for a sufficient # of objects they are likely to be distributed across all nodes). This decreases the # of keys requested per node but increases the total number of requests to the cluster. Because the bound was on throughput of requests (bound by CPU), minimizing the number of keys per request to a node doesn't help.
The proposed solution is to instead replicate nodes and load balance read requests. In this case, this doubles your read capacity, though you must write twice (or N times depending on your replication level).
- henrikschroder 17y agoIt's worth noting that that solution only works if you have much fewer writes than reads, but that's probably true for most people. A really simple way of doing this that all memcached clients should be able to handle is to set up two separate memcached clusters, write to both, and randomly read from either of them. That way you don't replicate nodes, you replicate the entire cluster. :-) A better solution would be to consolidate your items, i.e. make sure that items that often are fetched together with multi-get end up on the same server, however this requires a lot of extra knowledge about your data, and it's not very likely that this knowledge is available.
- anamax 17y ago> It's worth noting that that solution only works if you have much fewer writes than reads, but that's probably true for most people. Is it true of tweets? How about e-mail? What facebook content works that way? (IIRC the discussion of their new image store, one of the motivations was that most pictures were never viewed.)