Ottimizzazioni BEAM per Protocolli Binari: Lezione dal Case Study DNSimple

Quando gestisci una piattaforma che si occupa di registrazione domain, DNS hosting e infrastruttura cloud, le prestazioni non sono un optional. Sono la base su cui costruisci tutto. Per questo ci siamo incuriositi parecchio quando abbiamo trovato un'analisi dettagliata del team DNSimple sulla ottimizzazione di dns_erlang, la loro libreria DNS open source.

I numeri parlano chiaro: 12% di CPU in meno per query e 14% di query servite in più al secondo. Tutto senza toccare le NIF, solo ottimizzazioni native del BEAM. Se lavori con sistemi ad alto throughput in Elixir o Erlang, è una lettura che vale la pena.

Vediamo cosa c'è dietro.

Il Modello Mentale dei Binary nel BEAM

Una cosa che sorprende molti sviluppatori Elixir: appendere a un binary dentro un loop non è così costoso come si potrebbe pensare.

Quando scrivi qualcosa tipo:

def build_response(acc, []) do
  acc
end

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

Verrebbe da pensare a O(n²) — ogni iterazione crea un nuovo binary e copia tutto. Ma il BEAM è più furbo.

I binary sono immutabili. Il compilatore può dimostrare che se acc è stato appena creato da un append precedente e nessun altro tiene un riferimento, scrivere direttamente in quella memoria esistente è sicuro. La prima operazione alloca spazio extra, quelle successive scrivono dentro. Risultato? Costo ammortizzato O(1) per append — identico a come funziona uno std::vector in C++.

Il trucco? Se il tuo binary "scappa" — cioè viene salvato nel dizionario di un processo, restituito al chiamante, o appendato a qualcos'altro — la festa finisce. Si torna a copiare.

Questo pattern è ovunque nella gestione di protocolli binari. Quando costruisci risposte DNS in modo iterativo, mantenere quel flusso di accumulo stretto fa una differenza enorme.

Sub-binaries: Affettare Gratis (Quasi)

Quando fai pattern matching su binary, il BEAM crea i cosiddetti sub-binaries — termini minuscoli che puntano ai dati originali senza copiare nulla. Quando scrivi:

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

Nessun dato viene copiato. Rest è solo una finestra sul packet originale.

Ma c'è una sottigliezza che confonde molti: il BEAM mantiene internamente un contesto di match quando fai matching ricorsivo — praticamente un cursore che cammina tra i byte. Non materializza un sub-binary a meno che tu non lo faccia "scappare" davvero — restituirlo, salvarlo, passarlo da qualche parte dove potrebbe rimanere.

Per il parsing DNS questo conta tantissimo. Ogni query arriva come binary, viene processata contro la struttura del protocollo, e deve produrre una risposta. Capire quando stai creando lavoro effettivo contro quando stai solo osservando i dati è la differenza tra un parser che scala e uno che si blocca sotto carico.

Perché la Rappresentazione degli Interi Conta Più di Quanto Pensiamo

Su un BEAM a 64 bit, gli interi usano qualche bit per il type tag. Restano 60 bit per il valore vero. Gli interi che ci stanno sono "small integer" — valori immediati che vivono direttamente nei registri del processo, senza toccare mai l'heap.

Tutto ciò che è più grande diventa un bignum, che richiede allocazione sull'heap e considerazioni per il garbage collection. Sembra esoterico, ma diventa critico quando fai il bit-twiddling che il lavoro su protocolli binari richiede.

La tecnica si chiama SWAR (SIMD Within A Register) — impacchettare valori multipli in un singolo intero così puoi operare su tutti in parallelo a livello CPU. Per DNS significa parsare molti byte di dati in ogni operazione. Ma funziona solo se i valori impacchettati restano nel range "small integer".

Quando non ci stanno, non paghi solo in allocazioni — rischi di innescare cicli di garbage collection che altrimenti non esisterebbero. A milioni di query al secondo, quei cicli si sommano.

Cosa Significa per il Tuo Codice

Il takeaway pratico: non serve scrivere NIF o ricorrere a C per ottenere miglioramenti seri. Devi solo capire come il BEAM ragiona sui dati.

Alcuni pattern da interiorizzare:

1. Tieni stretti gli accumulatori binary. I loop che fanno solo append sono tuoi amici. Quando un binary scappa, il modello di costo cambia drammaticamente.

2. Fai matching sul posto quando puoi. Usa il pattern matching per osservare i dati invece di copiarli. Il BEAM è ottimizzato per questo.

3. Controlla le dimensioni dei tuoi interi. Quando fai aritmetica o manipolazione di bit, pensa se i tuoi valori resteranno nel range "small integer".

4. Profila tenendo a mente le reductions. Il BEAM schedula il lavoro in reductions (grossomodo chiamate di funzione). Un loop caldo che fa più matching in meno chiamate di funzione fa meno lavoro dal punto di vista dello scheduler.

Per chi costruisce sistemi che gestiscono protocolli binari — DNS, frame WebSocket, implementazioni di protocolli custom — questi pattern si applicano direttamente. Il BEAM ti dà strumenti incredibili per scrivere codice veloce, ma sono utili solo se ne capisci il modello.

Abbiamo visto team correre verso le NIF o Rust NIFs quando una comprensione più profonda della semantica BEAM avrebbe dato loro il 90% dei guadagni senza nessuna della complessità. Il runtime è più furbo di quanto gli diamo credito — il nostro lavoro è scrivere codice che gli permette di mostrarsi.

Da NameOcean pensiamo sempre alle prestazioni su larga scala. Che tu stia attivando Vibe Hosting per il tuo prossimo progetto o gestendo DNS per un'applicazione ad alto traffico, capire questi fondamenti ti aiuta a costruire sistemi che restano veloci quando le cose si fanno intense.

Buon coding, e possano i tuoi binary sempre appendere in modo efficiente.