Benchmarking Redis on Google Cloud Platform

Redis, the high-performance data structure server comes along with its own benchmarking tool. The tool is similar to Apache Bench (ab). I decided to benchmark Redis on Google Compute Engine VM instance and see what it looks like. 

My Setup

I decided to set up 2 Compute Engine instances. One instance will run the Redis Server and the other instance will run the Redis benchmarking tool.


Setting up Google Compute Engine Instances

You can use the gcloud tools to create instances or use the Web console (ofcourse there is an API option too, but we will leave that for now) to create the Compute Engine instances.

I used the Web console to create the 2 Compute Engine instances (redis-instance-1) and (redis-client-1) as given below:

  1. Assuming that you are in the Developers console and your project, Go to Compute –> Compute Engine –> VM Instances.
  2. Click on New Instance.
  3. In the name field, provide the names i.e. redis-instance-1 and redis-client-1
  4. In the zone, I chose us-central1-a
  5. In Machine Type, I went with the n1-standard-1 type (1 vCPU, 3.75 GB Memory). You can experiment with other machine types.
  6. I went with debian-wheezy for the OS image.
  7. Left the other values as defaults.
  8. Click on Create instance.

This will get 2 Compute Engine instances for you (redis-instance-1) and (redis-client-1). All we need to do now is to get Redis setup on both of them and that is the next step.

Setting up Redis on the Compute Engine Instances

The next step was to setup Redis on both redis-instance-1 and redis-client-1 instances. The steps below need to be repeated for each of the instances:

  1. SSH into the instance.
  2. The best way to setup Redis is the build from the sources. To do that, first update and install the necessary toolset on your Compute Engine instance.
    sudo apt-get update
    sudo apt-get install build-essential
  3. Once we are done with that, we can get the latest 3.0 Release of Redis and expand that as shown below:
    tar xvzf redis-stable.tar.gz
    cd redis-stable
  4. Now, let us build the software:
  5. Finally, let us install it :
    sudo make install

The above steps will get your instance setup with Redis and the all the applications i.e. redis-server, redis-cli, redis-benchmark, etc will be available.

Starting Redis on Compute Engine Instance

All we need to do now is to SSH into redis-instance-1 and start the Redis server (default) on that instance. The steps are straightforward:

  1. SSH into redis-instance-1 using gcloud command or the SSH button next to the instance in the VM Instances list. I like the later.
  2. Once you are into the session, simply give redis-server command as shown below:redisb1
  3. The server starts on port 6379 (default)

Allow Traffic on port 6379

In case you do not want to run the Redis benchmarking tool on another Compute Engine instance and instead want to do it from your local network, then you need to allow traffic on port 6379 i.e. the default Redis port.

To do that with the following steps:

  1. Assuming that you are in the Developers console and your project, Go to Compute –> Compute Engine –>  Networks.
  2. Click on the default network.
  3. You will see a default-allow-http rule. Click that and add a tcp:6379 value to the Allowed protocols and ports field as shown below:redisb2
  4. Click on Save.

Running the Benchmark tool from another Compute Engine instance

The last step was to SSH into the other Compute Engine instance (redis-client-1) and fire the following command:

redis-benchmark -h <IPAddress_RedisServerInstance> -n 100000 -q

This is a simple Redis benchmark test that simulates 100000 operations. Note that I need to provide the IP Address of the redis-instance-1 VM. The -q parameter is the quiet mode.

Note: From your Developer console, you can get the External IP Addresses from the Compute Engine –> VM Instances list. To get the internal IP Address, click on any of the Instances and the detail page should show you the Internal IP Address.

Refer to the Redis benchmarking tool page for more information.


We know that to talk from one Compute Engine instance to another, we can use either the Internal IP Addresses or External IP Addresses.

The results shown below is from a sample run when I use the Internal IP Address for the redis-instance-1.

PING_INLINE: 44722.72 requests per second
PING_BULK: 45871.56 requests per second
SET: 42753.31 requests per second
GET: 44111.16 requests per second
INCR: 44702.73 requests per second
LPUSH: 40535.06 requests per second
LPOP: 44543.43 requests per second
SADD: 45850.53 requests per second
SPOP: 42662.11 requests per second
LPUSH (needed to benchmark LRANGE): 46317.74 requests per second
LRANGE_100 (first 100 elements): 26539.28 requests per second
LRANGE_300 (first 300 elements): 13592.50 requests per second
LRANGE_500 (first 450 elements): 12081.67 requests per second
LRANGE_600 (first 600 elements): 9387.91 requests per second
MSET (10 keys): 37921.88 requests per second

The next set of results are when I use the External IP Address for the redis-instance-1.

<pre>PING_INLINE: 37285.61 requests per second
PING_BULK: 38431.98 requests per second
SET: 36968.58 requests per second
GET: 37425.15 requests per second
INCR: 37608.12 requests per second
LPUSH: 37064.49 requests per second
LPOP: 37299.52 requests per second
SADD: 36982.25 requests per second
SPOP: 36643.46 requests per second
LPUSH (needed to benchmark LRANGE): 35435.86 requests per second
LRANGE_100 (first 100 elements): 26329.65 requests per second
LRANGE_300 (first 300 elements): 12909.89 requests per second
LRANGE_500 (first 450 elements): 10563.01 requests per second
LRANGE_600 (first 600 elements): 8646.03 requests per second
MSET (10 keys): 33189.51 requests per second

Of course, I should do a few runs of the above test and then average things out, but you get the point. It should be straightforward now for you to probably extend these to across compute zones/regions and do a bench mark test from your local machine.


4 thoughts on “Benchmarking Redis on Google Cloud Platform

  1. Nicely done Romin.

    The results are basically what I’d expect out of this setup – the baseline could be improved with some tweaking of the default conf (e.g. did you disable persistence?) but it sounds about right 🙂

    It would be educational if you could repeat the benchmark but using memtier_benchmark ( – the reason is that with memtier_benchmark you can get to higher traffic volumes due to its multi-threaded design.

    Thanks for putting the time into writing this!

    1. Thank you for the feedback.

      No – I did not tweak the default conf. I should definitely look at doing that (atleast persistence). Thanks for the link to memtier_benchmark, something I could dig into next.

  2. Thanks Romin for a nice post. The clustering of times around the 44k and 37k per second levels, regardless of the operation, strongly suggests that networking delays, not redis activities, are dominating the overheads. Only the LRANGE results show significant Redis work. The -P (pipeline) option might let you create benchmark loads where Redis itself accounts for more than 50% of the response times.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s