Redis 2.2 October 27 th 2010 Pieter Noordhuis Who am I? Live in - - PowerPoint PPT Presentation

▶
redis 2 2
SMART_READER_LITE
LIVE PREVIEW

Redis 2.2 October 27 th 2010 Pieter Noordhuis Who am I? Live in - - PowerPoint PPT Presentation

Dec 20, 2023 157 likes •458 views

(whats new in) Redis 2.2 October 27 th 2010 Pieter Noordhuis Who am I? Live in Groningen, NL Redis contributor since March Backed by VMware So, whats new? Memory efficiency Throughput improvements Improved EXPIRE

slide-1
SLIDE 1

(what’s new in)

Redis 2.2

October 27th 2010

Pieter Noordhuis

slide-2
SLIDE 2

Who am I?

  • Live in Groningen, NL
  • Redis contributor since March
  • Backed by

VMware

slide-3
SLIDE 3

So, what’s new?

  • Memory efficiency
  • Throughput improvements
  • Improved EXPIRE semantics
slide-4
SLIDE 4

Memory efficiency

(lists) typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode;

slide-5
SLIDE 5

Memory efficiency

(lists)

typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode; typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode; typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode;
slide-6
SLIDE 6

Memory efficiency

(lists)

typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode; typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode; typedef struct listNode { struct listNode *prev; struct listNode *next; void *value; } listNode;

LPUSH RPUSH O(1)

slide-7
SLIDE 7

Memory efficiency

(lists)

  • O(1) is cool, but at what cost?
  • Pointer overhead is constant per element

0% 25% 50% 75% 100% 64 128 192 256 320 384 448 512

Linked list memory efficiency by payload size

Payload size (bytes)

slide-8
SLIDE 8

The ziplist

  • Save memory by using a little more CPU
  • Pack list in a single block of memory
  • Value header holds encoding / value length
  • O(memory size) LPUSH / LPOP

Value header Value Value header Value Value header Value List header

slide-9
SLIDE 9

The ziplist

  • Linked list memory efficiency improves for

larger payload. What is the gain of ziplists?

0x 2x 4x 6x 8x 10x 32 64 96 128 160 192 224 256

Ziplist memory gain by payload size

Payload size (bytes)

slide-10
SLIDE 10

The ziplist

  • Gain of ~4x for 32 byte payload
  • What is the throughput impact?

5000 10000 15000 20000

Time to LPUSH (32 byte payload) by list size

Time List size ziplist linked list

slide-11
SLIDE 11

The ziplist

  • Good fit for small payload, limited size
  • Redis uses the hybrid approach

list-max-ziplist-entries (default: 1024) list-max-ziplist-value (default: 32)

slide-12
SLIDE 12

Memory efficiency

(sets)

typedef struct dictEntry { void *key; void *val; struct dictEntry *next; } dictEntry;

Slot 0 value Slot 1 Slot 2 value value Slot 3 value

  • Backed by a hash table
  • O(1) access
  • Commonly holds integers

(think user IDs)

slide-13
SLIDE 13

Memory efficiency

(sets)

  • What is the cost of having the hash table?
  • Only consider 8-byte integers
  • Remember: lots of pointer-filled structs to

guarantee O(1) lookup

slide-14
SLIDE 14

The intset

  • Same idea as ziplist, but ordered
  • Fixed width values allow binary search
  • O(log N + memory size) SADD / SREM
  • O(log N) SISMEMBER

Integer Intset header Integer Integer Integer Integer Integer

slide-15
SLIDE 15

The intset

  • What is the gain of using an intset instead
  • f a hash table (for this integer range)?

0x 5x 10x 15x 20x 5000 10000 15000 20000

Intset (32-bit signed integer range) memory gain by set size

Set size

slide-16
SLIDE 16

The intset

  • Gain of ~10-15x
  • What is the throughput impact?

5000 10000 15000 20000

Time to SADD 32-bit integer by set size

Time hash table intset

slide-17
SLIDE 17

The intset

  • Good fit for size up to 20-50K
  • As with ziplists, hybrid approach

set-max-intset-entries (default: 4096)

slide-18
SLIDE 18

Memory efficiency

(misc.)

↓General keyspace overhead (VM enabled) ↓Sorted set metadata (~20%)

slide-19
SLIDE 19

Throughput

  • 1. AE_READABLE
  • 2. read(fd,buf);
  • 3. while(request = parseRequest(buf))

process(request);

  • 1. AE_WRITABLE
  • 2. while(response = buildResponse())

write(fd,response);

slide-20
SLIDE 20

Throughput

(response)

  • Glue responses into large chunks
  • Fixed buffer per connection (7500 bytes)
  • +1 for response with many bulk items
slide-21
SLIDE 21

Throughput

(response)

12500 25000 37500 50000 200 400 600 800 1000

LRANGE by response length

rps 2.0 2.2

slide-22
SLIDE 22

Throughput

(request)

  • General overhaul of processing code
  • Less complex & faster for multi bulk req.

3750 7500 11250 15000 100 200 300 400

MSET throughput by argument count

2.0 2.2

slide-23
SLIDE 23

EXPIRE

(new behavior)

  • Volatile keys (keys with EXPIRE set) are:
  • <= 2.0: deleted on write
  • >= 2.2: not touched
slide-24
SLIDE 24

EXPIRE

(new behavior)

redis> SADD online:<timestamp> 15 (integer) 1 redis> EXPIRE online:<timestamp> 600 (integer) 1 redis> SADD online:<timestamp> 23 (integer) 1 redis> SADD online:<timestamp> 27 (integer) 1 redis> SMEMBERS online:<timestamp>

  • 1. "15"
  • 2. "23"
  • 3. "27"
slide-25
SLIDE 25

max-memory

(purge policies)

  • When max-memory is hit, purge:
  • volatile key by random, TTL, LRU
  • any key by random, LRU (memcached)
slide-26
SLIDE 26

Other things in 2.2

  • Unix Sockets (tav)
  • LINSERT, LPUSHX, RPUSHX (Robey Pointer)
  • See “git diff 2.0.0” for things I’m forgetting...
slide-27
SLIDE 27

Work in progress

  • hiredis: easy to use C-client that ships with

a decoupled protocol parser

  • Memory fragmentation (tcmalloc, slabs, ...)
slide-28
SLIDE 28

Questions?