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!
Leave A Comment