RedisConf17 - Pain-free Pipelining
Download as PPTX, PDF1 like329 views
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.
RedisConf17 - Pain-free Pipelining
- 1. PAIN-FREE PIPELINING John Loehrer Joya Communications efficient Redis network i/o
- 4. • Client: INCR X • 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
- 6. COMPARE THROUGHPUT Single commands vs Pipelined
- 7. • single: 17k req/s • pipelined: 260k req/s QUICK BENCHMARK redis-benchmark -t get -c 1
- 8. SO WHAT? fast enough without pipelining
- 9. LOOPBACK != PROD need to simulate real network conditions
- 11. CONFIGURE TOXIPROXY • toxiproxy-cli create redis -l localhost:26379 -u localhost:6379 • toxiproxy-cli toxic add redis -t latency -a latency=1
- 12. • single: 216 req/s • pipelined: 4300 req/s NETWORK BENCHMARK 1 ms throttle
- 13. 0 15 30 45 60 localhost productio n CPU Network LOW-HANGING FRUIT Optimize CPU or Network?
- 14. OPTIMIZE RTT mitigate cost of network round-trips
- 15. PIPELINES FTW!
- 16. BUT …
- 17. PREPARE FOR THE PAIN
- 19. REFACTORING HURTS pipelining api is different from single calls
- 20. WHY NOT ASYNC?
- 21. • one connection for each command • requires different programming approach ASYNC I/O ISSUES
- 22. MY PARADIGM SHIFT pipeline everything
- 24. LEARN FROM MY MISERY After years of effort …
- 26. FAMILIAR API RedPipe works almost like redis-py
- 27. HOW IS IT DIFFERENT? • redis-py pipelines make you wait till payday • RedPipe gives you instant credit
- 29. WHAT’S THE POINT? Code Reuse & Flexibility
- 30. • assign data before you have it • return the response before it has been calculated • allows logical encapsulation even while pipelining
- 31. FUTURES WRAP RESPONSES Use them like the real thing
- 32. If it quacks … DUCK TYPING
- 33. USE CALLBACKS TO BUILD YOUR OWN FUTURES
- 34. NESTED PIPELINES
- 36. WRAP ANOTHER PIPE passes the commands upstream
- 37. WHAT ELSE? RedPipe has some other fun things …
- 38. KEYSPACES still works like redis-py
- 39. DEFINE YOUR DATA TYPE • strings • lists • sets • hashes • sorted sets • hyperloglog • geo (in progress)
- 40. SPECIFY A CONNECTION can talk to multiple backends transparently
- 41. CHARACTER ENCODING translate fields to a consistent data-type
- 42. SUPPORT COMPLEX TYPES hash fields support python primitives • bool • int • float • list • dict
- 43. WRITE YOUR OWN fields just need an encode/decode method
- 44. STRUCTS ability to manipulate redis like a dictionary … And still pipeline it all
- 45. QUESTIONS?
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.