Asynchronous Java Driver Blog     About     Archive     Feed

(Early) Targeted Routing Benchmarks

20 Jun 2014

In out last post we looks at what a targeted routing deployment looks like and how to enable it in the driver. It is time to see if all of our work pays off.

(Early) Benchmark

Building on our previous YCSB Benchmarking efforts we ran a quick test to see what if any performance improvement we would see. We decided to create a test scenario that any driver would have a difficult time with and spread a MongoDB cluster across a large geographical area. This will force a large latency between the client and shards.

TWe setup a simple deployment using Amazon EC2 spread across 3 data centers. We create two nodes in Northern Virginia, one node in Oregon, and one node in Northern California. One of the nodes in Northern Virginia hosted the YCSB Driver, a mongos, and the MongoDB configuration server. The second node in Virginia hosted a mongos and one of the shard servers. The Oregon and California nodes both hosted a mongos and a shard server. The cluster was sharded with three 1 node shards. We did not use replica sets for this test.

All of the nodes are based on the AMI’s produced by MongoDB Inc. for MongoDB 2.6.1 with 4000 IOPS. The AMI for each data center is listed below. All of the nodes are m3.xlarge.

The ycsb.usertable uses the { ‘_id’ : 1 } shard key and we pre-split and balanced the collection before the tests.

(Early) Results

We ran the workloada since it has a mix of reads and writes. The number of operations and documents was set to 100,000 for all runs. The number of connections was capped for each run at 5. The benchmark was run for each of the following permutations:

Latency

This first graph we will look at is the average latency for the update requests. The graph of the read latency is almost identical to the update results and is not provided.

Update Latency

We can see that as the number of threads for the mongodb-legacy and mongodb-async drivers grows so does t he latency for each request. This is due to the mongodb-legacy driver creating a queue of requests waiting for the socket to use and the mongodb-async driver doing the same within the socket buffers to the local mongos.

In contrast we see that the targeted-async driver is able to keep the latency of the request close to the minimum.

Throughput

While latency is important to make sure your systems respond in a timely manner, just as important is that the system be able to scale its ability to do more operations per unit of time. Given that the YSCB uses a synchronous interface and we intentionally created a high latency cluster there is an absolute maximum throughput for the system with a given number of threads. What we want to see is the throughput increase as the ability of the client (YCSB) increases. The graph below shows the throughput (operations/second) for each test run.

Throughput

Again, we see that the mongodb-legacy and mongodb-async drivers are capped by the throughput of the mongos. As we theorized the inability of the mongos to handle concurrent requests impacts the performance of the cluster as a whole.

We also see that the targeted-async exhibits exactly the behavior we want. As the number of YCSB threads increases the driver is able to receive and process more and more requests per second.

Final Thoughts

Please note that the targeted routing capability is provided via the driver’s extensions jar available to license holders. Please contact Allanbank Consulting, Inc. for information on licensing the driver and obtaining the extensions jar.

Over this series of blog posts we went from an idea on where and how we can get that next boost in performance. We looked at what the requirements are for a solution and got a little scared. We then realized that we didn’t need a perfect solution, just a different one. That lead us to the design and implementation of targeted routing in the Asynchronous Driver. Lastly we ran the tests and discovered that all of that work has paid off handsomely.

While we have been working on building up this capability for over a year we are releasing the targeted routing mode only as a user option. We plan to further enhance the capability over the next several months and eventually create a mode that will talk directly with the mongod processes in the sharded cluster directly.

Stay tuned to this blog for updates.