This is an update of the 2016 blog post How to put ArangoDB to Spartan-Mode.

When using a database like ArangoDB it is also important to explore how it behaves once it reaches system bottlenecks, or which KPIs (Key Performance Indicators) it can achieve in your benchmarks under certain limitations. One can achieve this by torturing the system by effectively saturating the resources using random processes.

This however will drown your system effectively – it may hinder you from capturing statistics, do debugging, and all other sorts of things you’re used to from a normally running system. The more clever way is to tell your system to limit the available resources for..

ArangoDB bundles its regular API Documentation also in Swagger.IO API description format. You can browse and explore it interactively via the ArangoDB Webinterface.

So you measured and tuned your system like described in the Part I and Part II of these blog post series. Now you want to get some figures how many end users your system will be able to serve. Therefore you define “scenarios” which will be typical for what your users do. One such a user scenario could i.e. be:

Following the previous blog post on performance analysis with pyArango, where we had a look at graphing using statsd for simple queries, we will now dig deeper into inspecting transactions. At first, we split the initialization code and the test code.

This is Part I of Performance analysis using pyArango blog series. Please refer here for: Part II (cluster) and Part III (measuring system capacity).

Usually, your application will persist of a set of queries on ArangoDB for one scenario (i.e. displaying your user’s account information etc.) When you want to make your application scale, you’d fire requests on it, and see how it behaves. Depending on internal processes execution times of these scenarios vary a bit.

We will take intervals of 10 seconds, and graph the values we will get there:

• average – all times measured during the interval,..

ArangoDB Packaging

With ArangoDB 3.0 we reworked the build process to be based completely on cmake. The packaging was partly done using cpack (Windows, Mac), for the rest regular packaging scripts on the SuSE OBS were used. With ArangoDB 3.1 we reworked all packaging to be included in the ArangoDB Source code and use CPack. Users can now easily use that to build their own Packages from the source, as we do with Jenkins. Community member Artur Janke (@servusoft) contributed the new ubuntu snap packaging assisted by Michael Hall (@mhall119). Big thanks for that!

Download packages for Snap..

We want to have a full chain of trust for our debian packages. Therefore the Suse Open Build Service (OBS) service signs them. We publish the key alongside the repository.

However, one can do better and do the validation right on apt-get install arangodb. Here’s how:

For running ArangoDB in clusters doing performance tests we wanted to have a non virtualized set of descent hardware with fast ethernet connection, enough RAM (since thats what Arango needs) and multicore CPU. Since you need a bunch of them, cheap ARM devel boards come to mind. The original Raspberry PI (we have those) is out of the game due to V8 is not supporting it anymore. The now available PI 2 doesn’t cut it, since its ethernet NIC is connected via USB (as on the original PI). The Odroid series only have one of both: Fast ethernet or enough RAM. The Cubieboard 4 wasn’t available yet,..

We’ve been using Callgrind with its powerful frontend KCachegrind for quiet some time to analyse where the hot spots can be found inside of ArangoDB. One thing always accounting for a huge chunk of the resource usage was string comparison. Yes, string comparison isn’t as cheap as one may think, but its been even a bit more than one would expect. And since much of the business of a database is string comparison, its used a lot.

ArangoDB and V8 use the ICU Library for these purposes (with no alternatives on the market) – so basically we heavily rely on the performance of the ICU library...