Building the Perfect Cassandra Test Environment

John BerrymanAugust 31, 2013

A month back, one of our clients asked us to set up 15 individual single-node Cassandra instances, each of which would live in 64MB of RAM and each of which would reside on the same machine. My first response was “Why!?”

Qualities of an Ideal Cassandra Test Framework

So what are the qualities of an ideal Cassandra test framework?

  • Light-weight and available — A good test framework will take up as little resources as possible and be accessible right when you want it.
  • Parity with Production — The test environment should perfectly simulate the production environment. This is a no-brainer. After all what good does it do you to pass a test only to wonder whether or not an error lurks in the differences between the test and production environments?
  • Stateless — Between running tests, there’s no reason to keep any information around. So why not just throw it all away?
  • Isolated — Most often there will be several developers on a team, and there’s a good chance they’ll be testing things at the same time. It’s important to keep each developer quarantined from the others.
  • Fault Resistant — Remember, we’re a little concerned here that Cassandra is going to be a resource hog or otherwise just not work. Being “fault resistant” means striking the right balance so that Cassandra takes up as little resources as possible without actually failing.

Implementing the Ideal Cassandra Test Framework

The first thing to do is to set up the test environment on a per-developer basis. This means changing a few paths. From cassandra.yaml change

  - /home/jberryman/cassandra/data
commitlog_directory: /home/jberryman/cassandra/commitlog
saved_caches_directory: /home/jberryman/saved_caches

And then in change


Next, it’s a good idea to create a wrapper around whatever client you’re using. This has several benefits. For one thing, creating a wrapper provides a guard against the client changing from under you. This is especially important right now since so many clients are scrambling to be CQL3 compliant. This wrapper is also a great place to stick any safeguards against horking up your production data when you think you’re running a test. Perhaps the easiest way to safeguard against this is to issue the CQL DESCRIBE CLUSTER statement and make sure that the cluster name is “TestCluster”. (If your CQL client doesn’t honor this statement, you can just create a keyspace called “Yes_ThisIsIndeedATestCluster” and test for its existence.) Once the wrapper is complete, it can be used with functional parity on both the test and production cluster.

The simplest way to make Cassandra light weight is to simply declare it so! In, simply change


However, just because you have now declared Cassandra to be light weight doesn’t mean that it will JustWork™. Given this little heap space to move in, Cassandra will happily toss you an OutOfMemory error on it’s first SSTable flush or compaction or garbage collection. To guard against this we have a bit of work to do!

The first thing to do is to reduce the number of threads, especially for reading and writing. In cassandra.yaml there are several changes to make:

rpc_server_type: hsha

Here, hsha stands for “half synchronous, half asynchronous.” This makes sure that all thrift clients are handled asynchronously using a small number of threads that do not vary with the amount of thrift clients.

concurrent_reads: 2;
concurrent_writes: 2
rpc_min_threads: 1;
rpc_max_threads: 1

As stated, the first two lines limit the number of reads and writes that can happen at the same time. 2 is the minimum number allowed here. The second two lines limit how many threads are available used for serving requests. Everything to this point serves to make sure that writes and reads can not overpower Cassandra during flushes and compactions. Next up:

concurrent_compactors: 1

If you are using SSD’s then this will limit the number of compactors to 1. If you’re using spinning magnets, then you’re already limited to a single concurrent compactor.

Next we need to make sure that we do everything we can so that compaction is not hindered. One setting here:

compaction_throughput_mb_per_sec: 0

This disables compaction throttling completely so that compaction has full reign over other competing priorities.

Next we turn all the knobs on memory usage as low as possible:

in_memory_compaction_limit_in_mb: 1

This is the minimal limit for allowing compaction to take place in memory. With such a low setting, much of compaction will take place in a 2-pass method that is I/O intensive — but I/O is not the thing we’re worried about!

key_cache_size_in_mb: 0

At the expense of read times, we can do away with key caches. But this may not even be necessary because we can do even better:

reduce_cache_sizes_at: 0
reduce_cache_capacity_to: 0

The first line say “As soon as you’ve used up this much memory, then reduce cache capacity.” And since this is set to 0, cache capacity is reduced just about as soon as Cassandra starts being used. The second line then dictates that the caches should effectively not be used at all.

Finally, on a test cluster, we’re not worried about data durability, so there are plenty of safeguards that we can simply do away with. For one, before starting the test cluster, go ahead and remove everything in the data dir and commitlog directories. Next, in cassandra.yaml set hinted_handoff_enabled: false. When creating a test keyspace, go ahead and set durable_writes = false so that the commit log is never even populated. Finally, when creating test tables, consider setting read_repair_chance = 0 and bloom_filter_fp_chance = 1. Though perhaps these modifications on keyspaces and tables are unnecessary because I was able to get pretty good performance without them.

Testing the Test Framework

Now since all of our changes are in place, let’s fire up Cassandra and see how she performs!

$ rm -fr /home/jberryman/cassandra && bin/cassandra -f

So far good. “Starting listening for CQL clients on localhost/″ means that we’re alive and ready to service requests. Now it’s time to slam Cassandra:

$ bin/cassandra-stress

Wow… so not only does it not die, it’s actually pretty darn performant! Looking back at the logs I see a couple warnings:

WARN 17:15:57,030 Heap is 0.5260566963447822 full.  You may need to reduce
memtable and/or cache sizes.  Cassandra is now reducing cache sizes to free up
memory.  Adjust reduce_cache_sizes_at threshold in cassandra.yaml if you don't
want Cassandra to do this automatically

Ah… this has to do with the reduce_cache_sizes_at, reduce_cache_capacity_to bit from earlier. After this warning we hits, we know that caches have been tossed out. Without caches, I wonder how that will affect the read performance. Let’s see!

$ bin/cassandra-stress --operation READ

Hooray, it works! And it’s still quite performant! I was concerned about the lack of caches killing Cassandra read performance, but it seems to be just fine. Looking back at the log file again, there are several more warnings each look about like this:

WARN 17:16:25,082 Heap is 0.7914885099943694 full.  You may need to reduce
memtable and/or cache sizes.  Cassandra will now flush up to the two largest
memtables to free up memory.  Adjust flush_largest_memtables_at threshold in
cassandra.yaml if you don't want Cassandra to do this automatically
WARN 17:16:25,083 Flushing CFS(Keyspace='Keyspace1', ColumnFamily='Standard1')
to relieve memory pressure

Despite the fact that we’re regularly having these emergency memtable flushes, Cassandra never died!

Popping open jconsole, we can make a couple more observations. The first is that while the unaltered Cassandra process takes up roughly 8GB of memory, this test Cassandra never goes over 64MB. Second, we also see that that the number of threads on the unaltered Cassandra hovers around 120-130 while the test Cassandra remains somewhere between 40 and 50.


So you see, my client’s request was actually quite reasonable and quite a good idea! Now they have a test framework that is able to support 15 developers on a single machine so that each developer has their own isolated test environment. This is a good example of how consultants sometimes learn from the companies they’re consulting.

How do you test Cassandra? We’d love to know?

More blog articles:

We've been Solr-istas since day one!

Our founder wrote the first book on Solr, now in 3rd edition. We've helped organizations from the US Patent and Trademark Office to Cisco build smarter search solutions with Solr.

Learn More about our Solr services.