Downloaded 14 times
Uploaded byRedis Labs
RedisConf17 - Pain-free Pipelining
The document discusses how pipelining commands can improve performance when making requests to Redis over a network. It shows that pipelining multiple commands together can increase throughput significantly by reducing the number of round trips needed to the server. The document provides a benchmark showing single commands getting 17k requests/second while pipelined commands achieve 260k requests/second. It also demonstrates how to simulate network latency using Toxiproxy to throttle connections and see even larger gains from pipelining when there is network overhead. The RedPipe library is introduced as a way to pipeline commands while still maintaining a familiar API and handling responses with futures to avoid blocking.
More Related Content
Similar to RedisConf17 - Pain-free Pipelining
RedisConf17 - Pain-free Pipelining
- 1. PAIN-FREE PIPELINING John Loehrer JoyaCommunications efficient Redis network i/o
- 2.
- 3.
- 4. • Client: INCRX • Server: 1 • Client: INCR X • Server: 2 • Client: INCR X • Server: 3 • Client: INCR X • Client: INCR X • Client: INCR X • Server: 1 • Server: 2 • Server: 3 SINGLE VS. PIPELINE
- 5.
- 6. COMPARE THROUGHPUT Single commandsvs Pipelined
- 7. • single: 17kreq/s • pipelined: 260k req/s QUICK BENCHMARK redis-benchmark -t get -c 1
- 8. SO WHAT? fast enoughwithout pipelining
- 9. LOOPBACK != PROD needto simulate real network conditions
- 10.
- 11. CONFIGURE TOXIPROXY • toxiproxy-clicreate redis -l localhost:26379 -u localhost:6379 • toxiproxy-cli toxic add redis -t latency -a latency=1
- 12. • single: 216req/s • pipelined: 4300 req/s NETWORK BENCHMARK 1 ms throttle
- 13. 0 15 3045 60 localhost productio n CPU Network LOW-HANGING FRUIT Optimize CPU or Network?
- 14. OPTIMIZE RTT mitigate costof network round-trips
- 15.
- 16.
- 17. PREPARE FOR THEPAIN
- 18.
- 19. REFACTORING HURTS pipelining apiis different from single calls
- 20.
- 21. • one connectionfor each command • requires different programming approach ASYNC I/O ISSUES
- 22. MY PARADIGM SHIFT pipelineeverything
- 24. LEARN FROM MYMISERY After years of effort …
- 25.
- 26. FAMILIAR API RedPipe worksalmost like redis-py
- 27. HOW IS ITDIFFERENT? • redis-py pipelines make you wait till payday • RedPipe gives you instant credit
- 28.
- 29. WHAT’S THE POINT? CodeReuse & Flexibility
- 30. • assign databefore you have it • return the response before it has been calculated • allows logical encapsulation even while pipelining
- 31. FUTURES WRAP RESPONSES Usethem like the real thing
- 32. If it quacks… DUCK TYPING
- 33. USE CALLBACKS TOBUILD YOUR OWN FUTURES
- 34.
- 35.
- 36. WRAP ANOTHER PIPE passesthe commands upstream
- 37. WHAT ELSE? RedPipe hassome other fun things …
- 38. KEYSPACES still works likeredis-py
- 39. DEFINE YOUR DATATYPE • strings • lists • sets • hashes • sorted sets • hyperloglog • geo (in progress)
- 40. SPECIFY A CONNECTION cantalk to multiple backends transparently
- 41. CHARACTER ENCODING translate fieldsto a consistent data-type
- 42. SUPPORT COMPLEX TYPES hash fieldssupport python primitives • bool • int • float • list • dict
- 43. WRITE YOUR OWN fieldsjust need an encode/decode method
- 44. STRUCTS ability to manipulateredis like a dictionary … And still pipeline it all
- 45.
Editor's Notes
- #3 We built our code so that any function can be pipelined with another. Took a lot of trial and error to realize we could do that and find efficient patterns to do so. Hindsight is 20/20.
- #4 the pic is of keystone XL pipeline. Also think of HTTP pipelining. Also called boxcarring.
- #6 Total API request time is often a function of number of network round trips * network latency. Tell story of fighting fire behind my house as a kid, with burlap sacks. Most people think about transaction support but I’ve always found LUA scripting a much better way to accomplish this. Pipelining is about improving network efficiency. You could try to do it with LUA, but then you can’t chain together smaller bits of logic together flexibly.
- #8 unscientific, but you can test it in your own environment
- #9 it all depends on what proportion of an api call is spent waiting on redis responses We use redis and found that a big chunk of time was spent talking to redis.
- #14 Made up numbers, but illustrates a point. On localhost I profile my app and find that a particular API call takes 6ms, and 1ms is spent making calls to redis. So I think I should spend my time optimizing CPU. Maybe I should rewrite my python app in Go (actually, maybe I should, but that’s a different talk). But if you profile a production environment, you see that network is actually a much bigger slice of the pie. Now I still spend 5ms on computation in python, but I spend 50ms talking to redis. Network is clearly the more fertile ground for optimization.
- #24 Tell story of the gate in west texas.
- #26 rewrite of all the ideas I’ve learned so far. What I would have written 3 years ago if I knew what I know now.
- #42 once you know the data type, you can make assumptions about the data going in and out of redis. Before that, you have to assume it’s all bytes.