HIgh Performance Redis- Tague Griffith, GoPro
â˘
3 gefällt mirâ˘1,432 views
High Performance Redis looks at a wide range of techniques - from programming to system tuning - to deploy and maintain an extremely high performing Redis cluster. From the operational perspective, the talk lays out multiple techniques for clustering (sharding) Redis systems and examines how the different approaches impact performance time. The talk further examines system settings (Linux network parameters, Redis system) and how they impact performance (both good and bad). Finally, for the developer, we look at how different ways of structuring data actually demonstrate different performance characteristics
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (19)
Ăhnlich wie HIgh Performance Redis- Tague Griffith, GoPro
Ăhnlich wie HIgh Performance Redis- Tague Griffith, GoPro (20)
Mehr von Redis Labs
Mehr von Redis Labs (20)
KĂźrzlich hochgeladen
KĂźrzlich hochgeladen (20)
HIgh Performance Redis- Tague Griffith, GoPro
- 1. High Performance Redis Tague Griffith
- 2. Development qProgramming qData restructuring qTransactions High Performance Redis Holistic understanding of some techniques and tricks for building out high performance Redis systems. Agenda Technology qRedis 2.x qTwemproxy qLinux Operations qClustering qFailover qOS Tuning qRedis Tuning
- 4. ⢠Software Architect with GoPro ⢠10+ years building distributed systems ⢠4+ years building with Redis ⢠Built multiple high performing Redis apps ⢠Previously: Apple, Netscape, Flickr Who Am I
- 5. Who Are You? Loki The Wolfdog
- 6. What is High Performance
- 7. ⢠Large number of clients ⢠High transaction rate ⢠Low response time ⢠Highly Available System Features
- 8. Main Techniques Ăź Large number of clients Ăź High transaction rate Ăź Low response time Ăź High Availability Ăź Low Response time Ăź High transaction rate Ăź Low response time Clustering and Failover System Tuning Programming Techniques
- 9. Clustering
- 10. ⢠Large number of clients ⢠High transaction rate ⢠Low response time ⢠Pre-requisite to high availability Features
- 11. Basic Sharding Client Client Client Client Client Shard-0 Shard-1 Shard-n ⢠Read/Writes same node ⢠Uniform workloads ⢠Key based partitioning
- 12. ⢠Needs a uniform work load ⢠Great for single key operations ⢠Traversals are expensive ⢠Node loss â roughly 1/N complete outage ⢠Hot keys are an issue Trade-offs
- 13. Read/Write Replicas Client Client Client Client Client Write Master Read Secondary Read Secondary ⢠Read/Writes split ⢠High Read workloads ⢠Different than Failover Replicas
- 14. ⢠Works well for high read workload ⢠Replication delay ⢠Lose read your writes consistency ⢠Node loss - depends on the node ⢠Easy to scale up hot keys Trade-offs
- 16. ⢠High performance reads ⢠Significant client coding ⢠Consistency goes out the window ⢠Node loss â depends on your approach ⢠Double the cost Trade-offs
- 17. ⢠Clustering techniques can be combined ⢠Sharding + R/W Replicas ⢠Sharding + Multi-Node ⢠Multi-node is a technique of last resort Hybrids
- 18. ⢠Scale horizontally not vertically ⢠Use multiple Redis instances per host ⢠R/W replicas or dedicated shards for hot keys ⢠Automate deployment and configuration Scaling Up
- 19. Happily Ever After Ăź Large Number of Clients Ăź High Transaction Rate q Highly Available q Low Response Time Letâs Party
- 20. Failover
- 21. ⢠Twemproxy ⢠Sentinel Out of the Box Failover Systems
- 22. Happily Ever After Ăź Large Number of Clients Ăź High Transaction Rate Ăź Highly Available q Low Response Time Letâs Party
- 23. System Tuning
- 24. ⢠Network tuning ⢠Persistence settings ⢠Small Aggregate Data settings Tuning
- 25. ⢠net.ipv4.ip_local_port_range ⢠net.ipv4.tcp_tw_recycle ⢠net.ipv4.tcp_tw_reuse ⢠net.core.somaxconn Network Tuning - Linux
- 26. ⢠tcp-backlog ⢠tcp-keepalive Network Tuning - Redis
- 27. ⢠hash-max-zipmap-entries ⢠hash-max-zipmap-value ⢠list-max-ziplist-entries ⢠list-max-ziplist-value ⢠zset-max-ziplist-entries ⢠zset-max-ziplist-value ⢠set-max-intset-entries Small Aggregate Data Switches
- 28. ⢠RDB ⢠Fork and Save ⢠AOF ⢠On âclientâ thread ⢠Fsync policy Persistence
- 29. Happily Ever After Ăź Large Number of Clients Ăź High Transaction Rate Ăź Highly Available q Low Response Time Letâs Party
- 31. ⢠Connection Management ⢠Transaction Structure ⢠Data Layout Key Areas to Consider
- 32. Persistent Connections ⢠Setup is expensive ⢠Reduced latency ⢠Server tuning maybe required Connection Management Operation Pipelining ⢠Substantial speedup (ops/s) ⢠Failure harder to manage ⢠Client support required Connection Pooling ⢠Form of persistent connections ⢠Reduced latency ⢠Client support required
- 33. The structure of your Redis transactions can greatly effect the performance of your app. Transaction Structure Smaller ⢠Lower latency ⢠Improved responsiveness ⢠Reduced throughput ⢠Negative impact onAOF Larger ⢠Higher latency ⢠Reduced responsiveness ⢠Increased throughput ⢠Less impact on AOF
- 34. Main Techniques ⢠Smaller Structures faster ⢠Pops off of long lists slow ⢠Internally âshardâ data if possible ⢠replace strings with denser coding (bit vector, map, etc) ⢠Moderate sized structures ⢠Reduce size of modifications ⢠Drop keys v. mutating ⢠Reduce impact on AOF Structured Types Memory Usage Isolate Modifications
- 35. Happily Ever After Ăź Large Number of Clients Ăź High Transaction Rate Ăź Highly Available Ăź Low Response Time Letâs Party
- 37. ⢠All environments are different ⢠Unexpected latency will make you cry ⢠For performance, scale horizontally ⢠Monitoring and Tools are Essential ⢠Connections are expensive ⢠Redundancy and Failover needs to be automatic ⢠AOF is a fair weather friend Take Aways
- 38. Questions?
- 39. Thanks!