Static Linux SDK with mimalloc, and toy Vapor benchmark

Server
1

The Static Linux SDK uses Musl, but there seem to be various opinions about Musl's allocator. I don't think it's a bad thing, but I wanted to see what a Static Linux SDK with a different allocator would be like, so I tried implementing one briefly.

As a means of achieving this, I've rewritten libc, so there may be something strange that happens.

If you are interested, we have also uploaded a ready-to-use container to GitHub.

We used the benchmarks from vapor-community, which were updated to vapor-4.

As far as I can tell, using Musl as it is seems to be a little slow. This benchmark is only for very simple iterations, so the difference may seem excessive, but we need to benchmark more accurately. However, it seems that the speed is not bad when the allocator is simply changed to mimalloc.

📊  Vapor 4 (Swift)
Booting...
📝  Testing GET /ping
🚀  Benchmarking
Running 5s test @ http://localhost:9000/ping
  4 threads and 128 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.46ms    4.47ms  63.67ms   91.28%
    Req/Sec     6.53k     0.93k    8.73k    79.00%
  130063 requests in 5.00s, 17.86MB read
Requests/sec:  26003.40
Transfer/sec:      3.57MB
53c1b01b39344b07d20db9a937e4a684e250a9c7f0bdd63e15e4ccc2ce63ba05

📊  Vapor 4 Musl (Swift)
Booting...
📝  Testing GET /ping
🚀  Benchmarking
Running 5s test @ http://localhost:9000/ping
  4 threads and 128 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.10ms    6.84ms  91.83ms   92.06%
    Req/Sec     4.40k   648.56     5.81k    84.50%
  87462 requests in 5.00s, 12.01MB read
Requests/sec:  17480.75
Transfer/sec:      2.40MB
1a75b34cf24bae6233b88ad4dba57072a8a74cccf2d666e29c338f433058d8d9

📊  Vapor 4 Musl + mimalloc(Swift)
Booting...
📝  Testing GET /ping
🚀  Benchmarking
Running 5s test @ http://localhost:9000/ping
  4 threads and 128 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.95ms    3.86ms  51.20ms   91.02%
    Req/Sec     7.09k     1.05k    9.03k    71.00%
  141193 requests in 5.00s, 19.39MB read
Requests/sec:  28216.29
Transfer/sec:      3.87MB
bfe7102b6ca7a9f85936f5d1802a89ebef05f6963472aa1736693f83323dbdd2

✅  Done

There is an article on Rust that does something similar, and it seems very good, so I'm applying it to the Static Linux SDK. For more details, please refer to the following blog.

4 Likes
2

Have you tried Vapor + mimalloc?

3

I have never experienced the combination of Swift and mimalloc before. We will see if this SDK will allow us to run applications with vapor, hummingbird, etc. using mimalloc in a stable manner.
It seems to work fine in simple benchmarking and verification.

4

Under heavy multithreaded contention to the allocator you an see very large performance penalties, for example in this (quite unrealistic) test case: Performance penalty from the Static Linux SDK. In that post I ran on a 16 core machine, but when I ran a real simulation on a 128 core machine, the performance difference was even larger. I think for small container apps the Musl default allocator is just fine but being able to switch from it to another one would be great.

1 Like
5

I missed your post, I'm thinking exactly the same thing, now that I've created a Dockerfile and have an easy to use environment, I'd like to try it out to see how much difference it makes in different applications.
It would be nice to just have a few allocators choices in the Swift SDK Generator. I agree that.

1 Like