Friend Core benchmarking

Friend Core is the foundation and central element of the Friend Unifying Platform. The core is written mainly in C and provides low-level system calls to our native applications. It integrates with various file systems, provides clustering with other core instances via Friend Network and ensures secure user data storage, just to name a few.

Multiple Friend Cores create our server-to-server node network and deliver data to and from our Workspace (image credit:

The embedded web server is a small, but important part of the core. Friend Core does not try to be a general-purpose web server, nevertheless much of the user experience depends on its performance.

The test setup consisted of two separate Linux machines connected with Gigabit Ethernet. Friend Core was built in release mode (no extra debugging facilities). Servers were running on a laptop with quad i7–7500U CPU @2.70GHz. Software versions: kernel 4.14.12, gcc 7.2.0, glibc 2.25-r9, curl 7.56.1, apache 2.4.27-r1, lighttpd 1.4.45, httperf 0.9.0.

I benchmarked three versions of Friend Core from different points in time from our repository, to check for any good/bad trends or regressions in performance. All software used its default configuration, so there certainly is some potential for fine-tuning.

Multiple connection handling

This is a very common workload on our demo and development servers, as obviously we want to serve as many users as possible with the same hardware. The results were obtained with httperf.

A year ago we faced some scaling issues, which were successfully resolved, so right now Friend Core can handle almost the same amount of connections as Apache and Lighttpd without any rejected clients. The slight degradation between Q3 2017 and Q1 2018 version is the result of adding new features and more error checking to make the code more robust.

Single client small file performance

This benchmark is important, because we care a lot about user experience. It also tells us if there are any obvious delays in the core. When the user starts an application it should appear immediately, like if it was running natively. The typical workload of starting a new application usually contains many small files. Timings were obtained with curl.

Conclusion: Friend Core is slightly better than Apache, slightly worse than Lighttpd. The differences are small.

Single client large file performance

This is a less common operation that can only happen when a user downloads a large file from his file systems, still we don’t want it to be a bottleneck.

Conclusion: In this case Friend Core performance is on par with Apache and slightly worse than Lighttpd.


The most important observation is that Friend Core running on a modern laptop can complete almost 7000 HTTP requests per second out-of-the-box. Of course this is just a synthetic benchmark. Adding more real users to an instance of the core can reveal other scaling issues, but the embedded web server is certainly not one of them.

The core is not solely a web server, yet still its performance closely matches Apache and Lighttpd. We plan to further optimize the core in the near feature, including gzip compression, sendfile support and better load distribution.