Measuring RESTHeart's Performances (Archived)

Our blog has moved to Medium


Measuring RESTHeart's Performances

26 January 2015  • SoftInstigate Team
Categories: en, technology  • Tags: restheart, mongodb

In the last few days we have spent a considerable amount of time measuring RESTHeart’s performances. We have gathered interesting information, the most relevant is that RESTHeart delivers excellent performances and it often overcomes the results that can be achieved accessing MongoDB directly.

RESTHeart delivers excellent performances and it often overcomes the results that can be achieved accessing MongoDB directly.

This requires some explanation as, of course, RESTHeart itself internally uses the MongoDB driver.

How can an HTTP layer, which internally uses the Java driver, be faster than accessing MongoDB directly via the Java driver alone? These results are possible because RESTHeart heavily optimizes the access to MongoDB resources: something you’d otherwise have to implement yourself adding a lot of complex Java code, if you want to achieve the same speed.

The below image summarizes the two architectures under test. The first row it’s a plain Java client, the MongoDB driver and MongoDB itself. The second row introduces the RESTHeart API Server and replaces the Java client with a much simpler HTTP RESTful client:

RESTHeart vs Java client

For example, in terms of pagination over a huge amount of documents, queries with significant skip parameter executes much faster, sometimes orders of magnitude better. This means that, for example, pagination over millions of documents can be performed hundreds of times faster, especially thanks to the eager pre-allocation DBcursor engine (recently added to RESTHeart’s development branch and available from the stable 0.9.8 binary release), which allows to skip documents very effectively.

The outcome is progressively more and more noticeable, as soon as the number of documents grows. You can read the original discussion thread which exposed the problem with MongoDB (“Poor performance paging through large result sets”) and led to the current solution.

We have also found that the execution time to create 1 million documents with random data using 200 test threads introduces only a 2,41% overhead to the total execution time, comparing RESTHeart plus MongoDB driver to the MongoDB driver alone. So, the performance penalties for adding a full HTTP layer on top MongoDB are negligible, while in most realistic scenarios you gain the above speed benefits.

We made the test case code available on Github as part of the RESTHeart source code. You can read the full article in a dedicated documentation page.