MongoDB Performance Issues - Fact or Fiction
Tags: mongodb, performance, wiredtiger
Published: 2017-08-03 23:16:19

---
title: MongoDB Performance Issues - Fact or Fiction
published: true
description: MongoDB has taken some publicity hits from performance issues in previous versions. This post will look at performance enhancements of newer versions.
tags: MongoDB, performance, WiredTiger
cover_image: https://thepracticaldev.s3.amazonaws.com/i/8wx7heerpv55meof4e5v.png
canonical_url: https://www.kenwalger.com/blog/nosql/mongodb/mongodb-performance-issues/ 

---

I see posts and hear conversations quite frequently about <a href="https://www.mongodb.com">MongoDB</a> performance issues. They are a frequent, and hot, topic on sites like Quora, Hacker News, and Reddit. Many of these "hits" against MongoDB are based on outdated data and older versions of MongoDB.

There was a movie from the late 1980's called <a href="https://www.amazon.com/gp/product/B00005N5SB/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=B00005N5SB&amp;linkCode=as2&amp;tag=kenwalgersite-20&amp;linkId=5916461a7aaf9df470882216c051fc99" target="_blank" rel="noopener">Crocodile Dundee II</a><img style="border: none !important; margin: 0px !important;" src="//ir-na.amazon-adsystem.com/e/ir?t=kenwalgersite-20&amp;l=am2&amp;o=1&amp;a=B00005N5SB" alt="" width="1" height="1" border="0" />. There is a scene in the movie where the guy from the Australian Outback, Mick "Crocodile" Dundee, is in a New York City hotel for the first time. Someone shows him that the room has a television. He turns it on and sees an old episode of <a href="https://www.amazon.com/gp/product/B013FCLEIG/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=B013FCLEIG&amp;linkCode=as2&amp;tag=kenwalgersite-20&amp;linkId=edf1c58d0b50bafcb2b416fb5135af32" target="_blank" rel="noopener">I Love Lucy</a>. Dundee shuts it off claiming he has already experienced television.

Similarly, many complaints from older versions of MongoDB still linger around. Someone who had a bad experience with an old version will answer a thread somewhere and claim "I used it once, didn't like it, it's garbage." Much like Mick Dundee, they are basing their entire opinion on outdated knowledge.

Let's take a look at some performance issues that are often raised and where things sit now with the latest version of MongoDB, <a href="https://docs.mongodb.com/manual/release-notes/3.4/">3.4.6</a>. I raised some of these aspects in a <a href="https://www.kenwalger.com/blog/nosql/new-version-new-features/">previous post</a>, but let's take a deeper dive.
<h3>The Jepsen Test &amp;Â Performance Issues of old</h3>
From a "documented issue" standpoint, many performance issues that plague MongoDB in social reviews are covered in a <a href="https://aphyr.com/tags/Jepsen">Jepsen</a> test result post from <a href="https://aphyr.com/posts/322-jepsen-mongodb-stale-reads">20 April 2015</a>. This was based on version 2.4.3. Or an even older article from <a href="https://aphyr.com/posts/284-call-me-maybe-mongodb">18 May 2013</a>. Clearly, there were some issues with data scalability and data concurrency in those earlier versions.

In fact, Jepsen has done extensive tests on MongoDB on lost updates and dirty and stale reads. Without getting too deep into the hows and whys of what was happening to the data, there were issues with writes when a primary went down, and read &amp; write consistency. These issues have been addressed as of version 3.4.1.
<h3>Product Enhancements</h3>
With the new data enhancements, MongoDB version 3.4.1 passed all of the Jepsen tests. Kyle Kingsbury, the creator of Jepsen, offered the following conclusions:
<blockquote class="block--ml block block--center" data-reactid="333">
<p data-reactid="334">MongoDB has devoted significant resources to improved safety in the past two years, and much of that ground-work is paying off in 3.2 and 3.4.</p>
</blockquote>
<blockquote class="block--ml block block--center padding--vertical-xs" data-reactid="335">
<p data-reactid="336">MongoDB 3.4.1 (and the current development release, 3.5.1) currently pass all MongoDB Jepsen tests….These results hold during general network partitions, and the isolated &amp; clock-skewed primary scenario.</p>
</blockquote>
<p data-reactid="336">You can read more about his conclusions in his <a href="https://jepsen.io/analyses/mongodb-3-4-0-rc3">published results</a>.</p>
<p data-reactid="336">Beyond data security, customers are finding huge benefits in performance in the more current releases of MongoDB. Improvements to, or the introduction of, technologies such as replication compression, the <a href="https://docs.mongodb.com/manual/core/wiredtiger/">WiredTiger</a> storage engine, in memory cache, and performance enhancements to sharding and replica sets have been a win for users.</p>

<h3 data-reactid="336">WiredTiger Case Study</h3>
A friend who works atÂ <a href="https://www.wanderu.com">Wanderu.com</a>, a MongoDB user, was very generous and forthcoming with some information about their MongoDB experience. When choosing a database option they felt that NoSQL, and MongoDB specifically, fit their business and data model better than a relational model would. They process a very diverse set of data for their bus and train travel application.

They take information from a vast assortment of bus and train vendors which arrive in XML, JSON, PDF, CSV, and other formats. Data is then ingested and transformed so that everything works with price checking and booking calls in vendor specific formats. The data model was determined to be incredibly complex and fragile for implementing in a relational database.

In May 2017, Wanderu migrated to the WiredTiger storage engine in MongoDB 3.4. They took some screenshots of some of their performance graphs that covered a 10 day period, five before and five after, their migration on 5/5. They were kind enough to share these images with me and approved of their use in this article.

[caption id="attachment_492" align="aligncenter" width="938"]<a href="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/active_reads-writes.png"><img class="wp-image-492 size-full" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/active_reads-writes.png" alt="MognoDB Active Reads/Writes" width="938" height="250" /></a> Before WiredTiger, the write load had a very limited max. After migration writes spiked as necessary.[/caption]

[caption id="attachment_495" align="aligncenter" width="925"]<a href="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/queued_read-writes.png"><img class="wp-image-495 size-full" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/queued_read-writes.png" alt="Queued Reads and Writes" width="925" height="224" /></a> Writes stayed fairly constant while queued reads fell dramatically.[/caption]

[caption id="attachment_493" align="aligncenter" width="925"]<a href="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/index_memory.png"><img class="wp-image-493 size-full" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/index_memory.png" alt="MongoDB Index Size" width="925" height="199" /></a> Index size took a dramatic decrease in size as well.[/caption]

[caption id="attachment_497" align="aligncenter" width="921"]<a href="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/memory_usage.png"><img class="wp-image-497 size-full" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/memory_usage.png" alt="MongoDB Memory Usage" width="921" height="215" /></a> Not surprisingly, Memory Usage dropped too.[/caption]

[caption id="attachment_494" align="aligncenter" width="924"]<a href="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/page_faults.png"><img class="wp-image-494 size-full" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/page_faults.png" alt="MongoDB Page Faults" width="924" height="212" /></a> Page Fault improvements[/caption]

[caption id="attachment_496" align="aligncenter" width="922"]<img class="wp-image-496 size-full" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/08/replication_log.png" alt="Replication Lag" width="922" height="214" /> If there wasn't a doubt, replication lag was improved as well.[/caption]

In the four years since Wanderu launched, it has relied heavily on MongoDB to store the station and trip information for each local, regional, and national carrier. With the new <a href="https://docs.mongodb.com/manual/reference/operator/aggregation/graphLookup/">$graphLookup</a> capability in MongoDB version 3.4, they are looking at the possibility of utilizing that technology for their graphing needs as well.
<h3>Further Industry Thoughts</h3>
MongoDB is a widely used NoSQL database. It is used by companies large and small, for a variety of reasons. I reached out to a few other known MongoDB users to get some real world feedback and product experiences.

<a href="https://www.carfax.com">CARFAX</a>, for example, has been using MongoDB in production since version 1.8. They load over a billion <a href="https://www.kenwalger.com/blog/nosql/document-model/">documents</a> a year and generate over 20,000 reports per second. <a href="https://twitter.com/JaiHirsch">Jai Hirsch</a>, a Senior Systems Architect at CARFAX, wrote a nice <a href="https://jaihirsch.github.io/straw-in-a-haystack//mongodb/2014/01/06/mongodb-legacy-migration/">write up</a> about why they decided on MongoDB. They have achieved some tremendous performance benefits from compressed replication.

<a href="https://www.ghx.com/">GHX</a> switched from MMAPv1 to WiredTiger with the 3.2 release of MongoDB. Jeff Sherard, their Database Engineering Manager, had another very positive experience.
<blockquote>Definitely the switch to WiredTiger in 3.2 was a huge boost. Especially on the compression side - we experience about 50% compression. Document level locking vs. Collection level locking also improved performance for us significantly.</blockquote>
He also experienced benefits with <a href="https://www.kenwalger.com/blog/nosql/mongodb-horizontal-scaling-sharding/">sharding</a> and <a href="https://docs.mongodb.com/manual/replication/">replica sets</a> as well with an upgrade to 3.4.4.
<blockquote>We recently upgraded to 3.4.4 and are particularly pleased with the improvements in balancing on shards (the parallelism makes balancing really fast). And the initial sync improvements in replicaSets [sic] have been really useful too.</blockquote>
<a href="https://www.tinkoff.ru/eng/">Tinkoff Bank</a> landed on using MongoDB instead of Oracle based on their finding that the performance of <a href="http://docs.oracle.com/javadb/10.6.2.1/ref/rrefclob.html">Oracle's CLOBs</a>Â are not as fast and are not searchable. They are able to process approximately 1,500 requests per second using their three node replica set. These queries put a load of 5-10% on the CPU of the <a href="https://docs.mongodb.com/manual/core/replica-set-primary/">primary node</a>.
<h3>Wrap Up</h3>
I'm sure that the SQL vs. NoSQL debate will live on. Much the same as Windows vs. Mac, or cats vs. dogs. I hope, however, that based on the information and testimonies provided here we can lay to rest the notion that MongoDB isn't "enterprise ready." If we are going to argue the virtues of MongoDB, we should at least be talking about the most current version.Â As in the scene with Mick Dundee, he comes across looking foolish for basing his entire view of a product based on something he experienced years ago.

There are several MongoDB specific terms in this post. I created a <a href="https://www.echoskillstore.com/MongoDB-Dictionary/45103">MongoDB Dictionary</a> skill for the <a href="https://www.amazon.com/gp/product/B01DFKC2SO/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=B01DFKC2SO&amp;linkCode=as2&amp;tag=kenwalgersite-20&amp;linkId=f9e513223de2525a72b95cf9561db55b" rel="noopener noreferrer">Amazon Echo</a>Â line of products. Check it out and you can say "Alexa, ask MongoDB what is a document?" and get a helpful response.

<hr />

<em>Follow me on Twitter <a href="https://www.twitter.com/kenwalger">@kenwalger</a> to get the latest updates on my postings.</em>