3 ms·
I'm certainly not trying to start a fight or anything, but there's a lot of bad testing out there, and people like trumpeting the results of such things. Havin
by dlsspy 16y ago
I'm certainly not trying to start a fight or anything, but there's a lot of bad testing out there, and people like trumpeting the results of such things.
Having more machines reduces the performance gained from multigets. This is often a pretty big performance boost. This is especially useful with synchronous clients that serialize requests across servers (which are very common in many popular languages because popular languages don't seem to encourage proper concurrency). Four times the number of servers will quite often make requests take four times longer.
Some of the memcached clients will do additional work to hash the keys using an independent node location key just to ensure locality of related data so the values can be retrieved more efficiently.
- antirez 16y agoSure, many tests are conducted in a wrong way, I fully agree. About multi-gets, this is how Redis handle this, we have a concept called key tags, that I think it is very similar to the one you described. Basically a key in the form foo{bar} gets hashed in a special way, only the part inside {} is hashed ('bar' in my example). So a client willing to optimize for multi get will use {user0}:name {user0}:surname and so forth. Well, not the perfect example as with Redis in this specific case you could use an Hash that is much more space efficient and will provide locality of related keys automatically.