This is a story of an excursion to the bottom of a deep rabbit hole, where I discovered a foot gun in `gcc`’s `libgcc`. The investigation has cost me several days and I hope that by writing this up I can entertain others and save them the journey.

TL;DR

If a C++ application is compiled with GCC on Linux and statically linked against a non-GLibC C-library (like `libmusl`), then there is a danger of a data race which leads to a busy loop happening after `main()` and all static destructors have finished. The race happens, if the application does not use `pthread_cancel` explicitly and if the..

To investigate the impact of the Meltdown and Spectre patches on the performance of ArangoDB, we ran benchmark tests with the two storage engines available in ArangoDB (MMFiles & RocksDB). We used the arangobench benchmark and test tool for these tests.

The tests include 10 different test cases with changing test parameters like concurrency, batch requests and asynchronous execution.

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:

For the ArangoDB 2.6 release from last week we’ve put some performance tests together. The tests will compare the AQL query execution times in 2.5 and 2.6.

The results look quite promising: 2.6 outperformed 2.5 for all tested queries, mostly by factors of 2 to 5. A few dedicated AQL features in the tests got boosted even more, resulting in query execution time reductions of 90 % and more. Finally, the tests also revealed a dedicated case for which 2.6 provides a several hundredfold speedup.

Also good news is that not a single of the test queries ran slower in 2.6 than in 2.5.

Some of the most frequent questions by new programmers learning Foxx have been about testing. While the HTTP API can easily be tested with any HTTP client and any JavaScript code that can be isolated from the ArangoDB APIs could be tested in similar environments like Node.js or io.js, it was all but impossible to test Foxx apps inside ArangoDB.

The upcoming release of ArangoDB sets out to change this. As of version 2.6, ArangoDB Foxx will come with full support for Mocha tests allowing you to use the same test framework for your frontend code in the browser, your server-side code running on..

ArangoDB is multithreaded and able to use several CPU-cores at once. Because of that access to common data structures to these threads have to be protected from concurrent access. ArangoDB currently uses mutexes, spinlocks and RW-locks for that. With the ongoing development of the MVCC the number of situations where protected access is needed grows significantly. If locking is done too often the scalability is effectively limited to one core. So this test was done to estimate the costs, and evaluate other solutions – so called lockless programming with atomics.

This version is deprecated. Download the new version of ArangoDB

Today I was asked to look at code that was supposed to read data from a MySQL data source, process it and then import it into ArangoDB.

ArangoDB has an HTTP interface to talk to its clients. Sometimes people want to secure this connection and use SSL or TLS instead. That is where we are using OpenSSL. It provides all the methods to implemented HTTPS on top of an HTTP server. It worked well and the corresponding code is only some 300 lines of C++ code. The biggest obstacle was the documentation. You can basically only learn from examples. That’s what we did. However, we finally encountered a bizarre bug. ArangoDB uses a number of threads to handle I/O in an asynchronous manner. The underlying library for I/O is libev. We span..

This is a follow to the post about ArangoDB 1.3 running on Raspberry PI. With the release of ArangoDB 1.4.0 I now tried to compile it again. As all patches required for 1.3 are part of 1.4.0 it is now much easier.