We’ve recently been working on improving ArangoDB’s throughput, especially when using the ArangoDB’s interface.

In this post, I will show some of the improvements already achieved, though the work is not yet finished. Therefore, the results shown here are still somewhat preliminary.

We wanted to measure improvements for ArangoDB’s HTTP interface, and so we used wrk as an external HTTP load generator.

During the tests, wrk called some specific URLs on a local ArangoDB instance on an otherwise idle machine. The test was run with ArangoDB 2.6 and devel. The ArangoDB instances were started with their default configuration.

wrk was invoked with varying amounts of client connections and threads, so the tests cover serial and concurrent/parallel requests:

bash invoking wrk

The number of connections ($CONNECTIONS) and threads ($THREADS) were both varied from 1 to 8. wrk requires at least as many connections as threads.

The first URL tested was a route in a simple Foxx application that inserts the data shipped in the HTTP request into a collection on the server. The internals of the route should not matter here, as this post focuses on the throughput improvements.

Following are the results for calling the route with wrk, comparing the stable ArangoDB version (2.6.3) with the current development version (head of devel branch as of today). The table shows the number of documents that were inserted during the 10 seconds the wrk client ran:

As can be seen above, devel was able to handle much more requests than 2.6 even with a single connection (i.e. serial client requests). Throughput was about 60 % higher for this case.

When increasing the number of client connections, the number of requests handled by devel ws also higher than that of 2.6, with improvements between around 25 and 70 %.

When increasing the number of client load generation threads, the picture doesn’t change much. Here’s the full table of results:

The next test consisted of inserting documents into a collection again, but using the built-in HTTP API for creating documents instead of a user-defined Foxx application. Throughput is expected to be higher than in the Foxx case because the built-in method is hard-wired and only serves a single purpose, whereas the Foxx route is user-definable and capable of doing fancy things, such as validating data, restricting access etc.

Here are the results for calling the hard-wired insertion route, again for 2.6 and devel:

devel provides higher throughput than 2.6 for this route as well. Improvements fell into the range of between 5 and 15 %. That’s not as impressive as in the Foxx route case above, but still a welcome improvement.

And of course we’ll try to improve the throughput further.

This article was published first on Jan’s Blog – Throughput Enhancements.