Part of blogging for myself is making notes about process that may or may not garner a wide audience.  The first of these notes will cover the process to build, configure, and benchmark redis that I’ve put together.

Building redis

  The first step is to obtain and build redis.  Since I regularly use both 32-bit and 64-bit versions of redis, I keep these source repositories and installation paths distinct.  The process looks like this:

mjbommar@verde:~/src$ git clone https://github.com/antirez/redis redis32
mjbommar@verde:~/src$ cd redis32/
mjbommar@verde:~/src$ make 32bit
mjbommar@verde:~/src$ sudo make PREFIX=/opt/redis32 install
mjbommar@verde:~/src$ sudo mkdir /opt/redis32/etc
mjbommar@verde:~/src$ sudo mkdir /opt/redis32/var/
mjbommar@verde:~/src$ sudo cp redis.conf /opt/redis32/etc/6379.conf
mjbommar@verde:~/src$ git clone https://github.com/antirez/redis redis64
mjbommar@verde:~/src$ cd redis64/
mjbommar@verde:~/src$ make
mjbommar@verde:~/src$ sudo make PREFIX=/opt/redis64 install
mjbommar@verde:~/src$ sudo mkdir /opt/redis64/etc
mjbommar@verde:~/src$ sudo mkdir /opt/redis64/var/
mjbommar@verde:~/src$ sudo cp redis.conf /opt/redis64/etc/6379.conf

Configuring redis

  Once redis has been installed to /opt/redis32 and /opt/redis64, I next tweak some of the configuration parameters in /opt/redis32/etc/6379.conf and /opt/redis64/etc/6379.conf.  Below is the list of changes, which make it easier to maintain multiple redis instances on one host for my typical usage.  Note that this configuration disables automatic saving; I prefer to let the application or user handle save scheduling, as the I/O and memory cost of SAVE and BGSAVE is significant.

  • daemonize yes
  • pidfile /opt/redis32/var/6379.pid
  • logfile /opt/redis32/var/6379.log
  • databases 2
  • Comment out all save lines
  • dbfilename 6379.rdb
  • dir /opt/redis32/var
  • appendfsync no
  • Tweak the hash-max-*, list-max-*, set-max-*, and zset-max-* variables if known a priori for problem.

Running and benchmarking redis

  Once we have redis installed and configured, it’s time to run and benchmark.  This stage looks like the following:

mjbommar@verde:~/src$ cd /opt/redis64
mjbommar@verde:/opt/redis64$ sudo nice -n -10 bin/redis-server etc/6379.conf

  At this point, the server should be running. We can check in (at least) two ways:

mjbommar@verde:/opt/redis64$ ps aux | grep redis
mjbommar@verde:/opt/redis64$ bin/redis-cli INFO

  And it’s finally time to benchmark. While redis-benchmark runs a whole suite of redis commands, I find just GET and SET to be enough to test the host hardware and compiler.

mjbommar@verde:/opt/redis64$ bin/redis-benchmark -t GET,SET
====== SET ======
  10000 requests completed in 0.07 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
138888.89 requests per second

====== GET ======
  10000 requests completed in 0.06 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
153846.16 requests per second

  If you want machine readable or even less verbose output, you can also pass the -q flag:

mjbommar@verde:/opt/redis64$ bin/redis-benchmark -q -t GET,SET
SET: 149253.73 requests per second
GET: 151515.16 requests per second

  Note that there are better results to be had if you can afford to use Unix/IPC sockets instead of TCP; while you can’t cluster/shard across machines using Unix sockets, these TCP loopback results are more than 25% slower than using Unix sockets.

Happy redis-ing!