3 ms·

Hello dlsspy, I never tested memcached, but I'm really sure about Redis numbers: you can get 150k ops/sec in a decent Linux box without problems, per core. So i

by antirez 17y ago

Hello dlsspy, I never tested memcached, but I'm really sure about Redis numbers: you can get 150k ops/sec in a decent Linux box without problems, per core. So if you got 4 cores you can get 600k ops/sec, assuming you'll have enough bandwidth to saturate that. I agree with you that if Redis performance is better than memcached there is to fill a bug or start a conversation, as there is something odd. Both are written in C and use multiplexing internally, against the same OSes. The performances should be very similar, or the memcached performances should be better as it supports less features. Edit: p.s. can you please explain why running multiple memcached processes, one per core, was not good enough?

dlsspy 17y 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 ago
  Sure, 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.

by antirez 17y ago

dlsspy 17y 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 ago
Sure, 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.