Sunday, 31 January 2016

How to stress test CouchDB with Gatling

In this blog post, I am going to show you how to use Gatling ( to test the performance of CouchDB's HTTP operations.

Gatling is an HTTP performance tool written in Scala with the Akka and Netty toolkits.Via Akka and Netty, Gatling can generate a large amount of load, while making efficient use of threads (those libraries are all based on non-blocking I/O). It is a JVM application, therefore, you can run it on a variety of platforms without a problem.

Gatling provides you with a Domain Specific Language for writing simulations to generate load on (among other things) HTTP-based services such as CouchDB. The DSL is written in Scala and provides a fluent interface. It provides convenience mechanisms for triggering HTTP methods (GET, PUT, POST, DELETE), as well as simulating wait times and "arrival" times of user.

I've put together a sample Maven project which illustrates one approach for running Gatling stress tests via the command line. Have a look at: 
You only need Apache Maven and a JDK to run the sample. Gatling embeds a version of the Scala compiler so you don't need to have one running.

The sample project contains a single simulation which does the following against a CouchDB server:

  • Each synthetic user creates a database
  • Each synthetic user proceeds to add a number of JSON docs to that database
  • Once documents have been added, each synthetic user deletes the database
You fill find further instruction on the Github page on how to run the simulation.

Gatling produces nice charts with details about response time and throughput (even for specific HTTP operations) so it gives you and idea of what the performance and bottlenecks are.

Here are some examples:

Previously, I had used similar simulations to stress-test BigCouch clusters and the code can be reused out of the box to test CouchDB 2.0 clusters. I've also shared some Ansible recipes to make the deployment of CouchDB 2.0 a bit easier. Have a look at


  1. Hi Guillaume,

    Great info, what you might want to include in your test is:
    1) reading back the records by the doc name
    2) querying for records that match a criteria (some value you put in some documents and not others)

    From my experience / test of couch db:
    1) reading won't have a significant performance hit but it may in other db's? most web applications do as much or more reading than writing.
    2) this is the area that can make couch db work, particularly if one user is adding documents to a db causing a query to re-index.

    Good luck with your testing.


  2. I really appreciate information shared above. It’s of great help. If someone want to learn Online (Virtual) instructor lead live training in Couch DB, kindly contact us
    MaxMunus Offer World Class Virtual Instructor led training on Couch DB. We have industry expert trainer. We provide Training Material and Software Support. MaxMunus has successfully conducted 100000+ trainings in India, USA, UK, Australlia, Switzerland, Qatar, Saudi Arabia, Bangladesh, Bahrain and UAE etc.
    For Demo Contact us.
    Nitesh Kumar
    Skype id: nitesh_maxmunus
    Ph:(+91) 8553912023