How to speed up Akkoma (and Pleroma)

Bdx.town is running Elixir since its beginning around the year 2020. We first started with Pleroma, and then moved to Akkoma when the trend hit us attracted by the faster development pace of this software and its cooler overall brand 😎.

Our little instance is running on a little server hosted in the Netherlands and powered by wind energy. We like to keep things small and reasonable for as long as possible, and because of that, we rely on a single server (running multiple dockerized services).

It first went well for the first 20 users, but things started to go slower and slower, despite the regular power boost we injected into the server. I started to lose hope and to give in to the “put more steam in the engine” trend, but then, then I read the docs.

RTFM

Akkoma and Pleroma are built on top of the Erlang/OTP virtual machine called BEAM. In order to reduce latency, BEAM does something called busy waiting; basically, it does placeholder operations that keep appearing as busy for the OS, and it keeps allowing CPU time for it. If, despite being considered an anti-pattern most of the time, busy waiting in BEAM allows the Akkoma process to answer requests faster, it is doing that at the expense of other processes.

As long as BEAM is running on a dedicated server, things can be great with busy waiting. Sadly, it’s not our case, and probably it will be the same for the majority of Akkoma and Pleroma hosts. By seizing CPU time while messing around, BEAM prevents other software from doing calculations.

What’s the point of having a fast Akkoma if PostgreSQL, which is doing all the heavy database work, is slow as hell because it cannot calculate anything?

Act

Hopefullly busy waiting can be deactivated by editing the arguments that are passed to the BEAM VM at boot:

+sbwt none
+sbwtdcpu none
+sbwtdio none

In our case (we are using a docker image based on the one provided by the AkkomaGang), this vm.args file is located at /opt/akkoma/releases/3.9.3-0-g80519fe/vm.args (you should probably check your erlang version and edit that path accordingly).

By doing so our little server and its lonely CPU were able to answer faster to requests, since Postgres can now do its job.