Afmystificering af BEAM-binærer: Sådan gjorde vi vores DNS-bibliotek lynhurtigt (uden brug af NIFs)

Når du driver en platform, der håndterer domæregistrering, DNS-hosting og cloud-infrastruktur, som vi gør hos NameOcean, er ydeevne ikke bare en luksus – det er fundamentet for pålidelighed. Det er derfor, vi bliver begejstrede, når vi ser smarte optimeringshistorier fra Erlang-økosystemet, og hvorfor vi gerne vil gennemgå en af vores favoritter for dig.

For nylig stødte vi på et fascinerende dybdedyk fra DNSimple-teamet om deres arbejde med at optimere dns_erlang, deres open-source DNS-bibliotek. Deres resultater var opsigtsvækkende: 12 % mindre CPU per forespørgsel og 14 % flere forespørgsler serveret per sekund – alt sammen fra rene BEAM-optimeringer, uden brug af NIFs. For alle, der bygger systemer med høj gennemstrømning i Elixir eller Erlang, er dette obligatorisk læsning.

Lad os pakke ud, hvad der gør dette muligt.

BEAM Binary Mental Model

Her er noget, der overrasker mange Elixir-udviklere: at tilføje (append) til binære data i et tæt loop er ikke så dyrt, som man skulle tro.

Når du skriver noget som:

def build_response(acc, []) do
  acc
end
def build_response(acc, [h | t]) do
  build_response(<<acc::binary, h>>, t)
end

Vil du forvente, at det er O(n²) – hvor hver iteration skaber en ny binær og kopierer alt. Men BEAM er smartere end det.

Da binære data er uforanderlige (immutable), kan compileren bevise, at hvis acc lige er blevet oprettet af en tidligere append, og ingen andre holder en reference til den, så er det sikkert at skrive direkte ind i det eksisterende hukommelsesområde. Den første append allokerer lidt ekstra kapacitet, og efterfølgende appends skriver ind i den. Resultatet? Amortiseret O(1) per append – identisk med hvordan en std::vector fungerer i C++.

Hagen? Hvis din binære data "undslipper" (escapes) – hvilket betyder, at den gemmes i en proces-ordbog, returneres til en kalder eller tilføjes til noget andet – så er festen slut. Så er du tilbage til kopiering.

Dette mønster optræder overalt i håndtering af binære protokoller. Når du bygger DNS-svar iterativt, betyder det enormt meget at holde den akkumulator-strøm stram.

Sub-binaries: Gratis slicing (stort set)

Matching på binære data skaber det, som BEAM kalder sub-binaries – små termer, der peger ind i de oprindelige data uden at kopiere. Når du skriver:

<<Header:12/binary, Rest/binary>> = Packet

Bliver der ikke kopieret nogen data. Rest er blot et vindue ind i den oprindelige pakke.

Men her er den subtilitet, der snyder folk: BEAM holder en intern match-kontekst, når du matcher rekursivt – essentielt en markør, der bevæger sig gennem bytesene. Den vil ikke materialisere en sub-binary, medmindre du rent faktisk lader den undslippe – ved at returnere den, gemme den eller sende den et sted hen, hvor den bliver hængende.

Dette betyder enormt meget for DNS-parsing. Hver forespørgsel ankommer som en binær, matches mod protokolstrukturen og skal producere et svar. At forstå, hvornår du skaber arbejde, versus hvornår du blot kigger på data, er forskellen på en parser, der skalerer, og en, der kvæles under belastning.

Hvorfor integer-repræsentation betyder mere, end du tror

På en 64-bit BEAM optager heltal (integers) et par bits til deres type-tag. Det efterlader 60 bits til selve værdien. Heltal, der passer ind i det rum, er "små heltal" (small integers) – umiddelbare værdier, der lever direkte i proces-registrene og aldrig rører heapen.

Alt, der er større, bliver til et "bignum", hvilket kræver heap-allokering og overvejelser omkring garbage collection. Det lyder esoterisk, men det bliver kritisk, når du laver den form for bit-manipulation, som binær protokol-arbejde kræver.

Teknikken kaldes SWAR (SIMD Within A Register) – at pakke flere værdier ind i et enkelt heltal, så du kan operere på dem parallelt på CPU-niveau. For DNS betyder det at parse mange bytes data i hver operation. Men det virker kun, hvis dine pakkede værdier passer ind i "small integer"-sweetspotet.

Når de ikke gør, betaler du ikke kun for hukommelsesallokering – du risikerer potentielt at udløse garbage collection-cyklusser, som ellers ikke ville eksistere. Ved millioner af forespørgsler per sekund løber de cyklusser op.

Hvad dette betyder for din kode

Her er den praktiske læring: Du behøver ikke skrive NIFs eller række ud efter C for at opnå seriøse performance-gevinster. Du skal forstå, hvordan BEAM tænker over data.

Her er et par mønstre, der er værd at indprente sig:

1. Hold binære akkumulatorer stramme. Append-only loops er din ven. Når en binær data undslipper, ændres omkostningsmodellen drastisk.

2. Match på stedet, når det er muligt. Brug pattern matching til at se på data frem for at kopiere det. BEAM er optimeret til dette.

3. Hold øje med dine integer-størrelser. Når du laver aritmetik eller bit-manipulation, så tænk over, om dine værdier vil forblive i "small integer"-området.

4. Profilér med reduktioner for øje. BEAM planlægger arbejde i reduktioner (omtrent antallet af funktionskald). Et "hot loop", der laver mere matching i færre funktionskald, gør mindre arbejde fra schedulerens perspektiv.

For alle, der bygger systemer, der håndterer binære protokoller – uanset om det er DNS, WebSocket-frames eller specialiserede protokol-implementeringer – gælder disse mønstre direkte. BEAM giver dig utrolige værktøjer til at skrive hurtig kode, men de er kun nyttige, hvis du forstår modellen.

Vi har set teams række ud efter NIFs eller Rust NIFs, når en dybere forståelse af BEAM-semantikken ville have givet dem 90 % af gevinsterne uden kompleksiteten. Runtime-miljøet er smartere, end vi ofte giver det kredit for – vores job er at skrive kode, der lader det vise sig frem.

Hos NameOcean tænker vi altid på performance i stor skala. Uanset om du er ved at sætte Vibe Hosting op til dit næste projekt eller administrerer DNS for en applikation med høj trafik, hjælper forståelsen af disse fundamentale principper dig med at bygge systemer, der forbliver hurtige, når der er travlt.

God kodning, og må dine binære data altid kunne append effektivt.