Blog

Building, configuring, and benchmarking redis from Github source

  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:

[email protected]:~/src$ git clone https://github.com/antirez/redis redis32
[email protected]:~/src$ cd redis32/
[email protected]:~/src$ make 32bit
[email protected]:~/src$ sudo make PREFIX=/opt/redis32 install
[email protected]:~/src$ sudo mkdir /opt/redis32/etc
[email protected]:~/src$ sudo mkdir /opt/redis32/var/
[email protected]:~/src$ sudo cp redis.conf /opt/redis32/etc/6379.conf
[email protected]:~/src$ git clone https://github.com/antirez/redis redis64
[email protected]:~/src$ cd redis64/
[email protected]:~/src$ make
[email protected]:~/src$ sudo make PREFIX=/opt/redis64 install
[email protected]:~/src$ sudo mkdir /opt/redis64/etc
[email protected]:~/src$ sudo mkdir /opt/redis64/var/
[email protected]:~/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:

[email protected]:~/src$ cd /opt/redis64
[email protected]:/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:

[email protected]:/opt/redis64$ ps aux | grep redis
[email protected]:/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.

[email protected]:/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:

[email protected]:/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!

Leave a Comment

Your email address will not be published. Required fields are marked *