Reply to a comment

reply_to_blog.txt

This is my reply to Alex Mills: http://www.binpress.com/tutorial/introduction-to-rate-limiting-with-redis/155

Yes, with threads, processes, or an async reactor. That said...

$ redis-benchmark -n 2000000 -c 20 -q
[snip]
SET: 115141.05 requests per second
GET: 134048.27 requests per second
INCR: 180505.41 requests per second
LPUSH: 176056.33 requests per second
LPOP: 181488.20 requests per second
SADD: 178412.12 requests per second
[snip]

$ redis-benchmark -n 2000000 -c 5 -P 4 -q
[snip]
SET: 515463.91 requests per second
GET: 339558.59 requests per second
INCR: 325203.25 requests per second
LPUSH: 324149.12 requests per second
LPOP: 427350.44 requests per second
SADD: 550964.19 requests per second
SPOP: 602409.69 requests per second
[snip]

$ redis-benchmark -n 2000000 -c 1 -P 20 -q
[snip]
SET: 685400.94 requests per second
GET: 771902.69 requests per second
INCR: 759878.44 requests per second
LPUSH: 713521.25 requests per second
LPOP: 697350.06 requests per second
SADD: 752445.44 requests per second
SPOP: 840336.12 requests per second
[snip]

Profiles done on the Redis side of things have shown that the vast
majority of time spent handling common requests (like the ones in the
benchmark above) are system calls - 97% of the time, according to
results presented at Redisconf 2015. Pipelines multiply Redis
performance by helping to minimize system calls for network IO, as
well as reducing the number of network packets to be sent. And to
make matters even more confusing, people have found that Redis
performs *better* when behind some types of proxies (Twemproxy by
Twitter, for example), because the proxy collects requests together
into pipelines automatically.