4 ms·

memcached's ASCII protocol is known to be slower and less effective than the binary protocol and using TCP for memcached is slower than using UDP. It's not a fa

by crad 16y ago

memcached's ASCII protocol is known to be slower and less effective than the binary protocol and using TCP for memcached is slower than using UDP. It's not a fair assertion that redis is faster than memcached when you're picking the slowest way to communicate with memcached. Also, one should not expect to see parity in get/set ratios or you're doing it wrong. Cache get with a good hit ratio/high effectiveness is the point of memcached. While memcached gets effectively plateaued in his low concurrency example, redis get performance degraded as you added more clients/concurrency. In an unoptimized use of memcached, high transaction rate environment, I see sets at 10% of gets. Redis may very well be faster, but an effective benchmark should be closer to real world use case and shouldn't hold one party back for parity in protocol complexity.

antirez 16y ago
Crad: I compared the same protocols, both TCP, both ASCII protocol. This is a fair comparison for sure with TCP, as with UDP you have many tradeoffs, so this is specifically a comparison of the TCP (reliable) protocol you can use with Redis. About the binary protocol: I think this is currently not the widely deployed one, but the point here is that if the difference is about the protocol, even Redis could switch to a faster protocol using a binary one. Using almost the same protocol in both servers we are actually measuring the internals. Anyway your reasoning can be applied the other way around. Many memcached systems are currently using CAS extensively while you can perform just one query with Redis atomic operations in many of the same real world scenarios. So should I double the Redis numbers by two because there is a faster way to do something in a Redis specific way? About SET/GET ratio, I measured both SET and GET performances in an independent way, so I don't get it.
- crad 16y ago
  I get your reasoning about ASCII/TCP and it makes sense... apples to apples. When asking for a performance benchmark, specifically about systems that are very dependent on communication protocol for performance, I think that it's more valuable to know how the best performing protocol of either side would perform. As far as atomic vs CAS, I'd be more interested in the "right way" than the same way, so for my own interest, yes. Re: Ratio, from your graph it appeared they were co-mingled. If each was done on their own then my point is moot.
- saurik 16y ago
  This assumes the people developing memcached decided to spend a lof of time optimizing their implementation of the ASCII protocol, despite knowing that performance conscious users wouldn't use it anyway; while it may very well be true (I don't remember), it doesn't seem like something that is safe to take for granted.

by crad 16y ago

antirez 16y ago

Crad: I compared the same protocols, both TCP, both ASCII protocol. This is a fair comparison for sure with TCP, as with UDP you have many tradeoffs, so this is specifically a comparison of the TCP (reliable) protocol you can use with Redis. About the binary protocol: I think this is currently not the widely deployed one, but the point here is that if the difference is about the protocol, even Redis could switch to a faster protocol using a binary one. Using almost the same protocol in both servers we are actually measuring the internals. Anyway your reasoning can be applied the other way around. Many memcached systems are currently using CAS extensively while you can perform just one query with Redis atomic operations in many of the same real world scenarios. So should I double the Redis numbers by two because there is a faster way to do something in a Redis specific way? About SET/GET ratio, I measured both SET and GET performances in an independent way, so I don't get it.

crad 16y ago
I get your reasoning about ASCII/TCP and it makes sense... apples to apples. When asking for a performance benchmark, specifically about systems that are very dependent on communication protocol for performance, I think that it's more valuable to know how the best performing protocol of either side would perform. As far as atomic vs CAS, I'd be more interested in the "right way" than the same way, so for my own interest, yes. Re: Ratio, from your graph it appeared they were co-mingled. If each was done on their own then my point is moot.
saurik 16y ago
This assumes the people developing memcached decided to spend a lof of time optimizing their implementation of the ASCII protocol, despite knowing that performance conscious users wouldn't use it anyway; while it may very well be true (I don't remember), it doesn't seem like something that is safe to take for granted.