Разоблачение бинарных файлов BEAM: как мы сделали нашу DNS-библиотеку молниеносной (без использования NIF)

Когда вы управляете платформой, которая занимается регистрацией доменов, DNS-хостингом и облачной инфраструктурой, как мы в NameOcean, производительность — это не просто приятное дополнение, а фундамент надежности. Вот почему мы радуемся, когда видим истории об умной оптимизации в экосистеме Erlang, и почему мы хотим разобрать для вас один из наших любимых примеров.

Недавно мы наткнулись на захватывающее глубокое исследование от команды DNSimple об их работе по оптимизации dns_erlang, их open-source библиотеки для DNS. Их результаты поражают: на 12% меньше использования CPU на запрос и на 14% больше запросов, обрабатываемых в секунду — и всё это благодаря чистой оптимизации BEAM, без использования NIF. Для любого, кто строит высокопроизводительные системы на Elixir или Erlang, это обязательное к прочтению.

Давайте разберем, что делает это возможным.

Ментальная модель бинарных данных в BEAM

Вот что удивляет многих Elixir-разработчиков: добавление (append) в бинарные данные в тесном цикле обходится не так дорого, как вы могли бы подумать.

Когда вы пишете что-то вроде:

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

Вы можете ожидать, что сложность будет O(n²) — каждая итерация создает новый бинарный объект и копирует всё содержимое. Но BEAM умнее.

Поскольку бинарные данные неизменяемы, компилятор может доказать: если acc только что был создан предыдущим добавлением и на него больше нет ссылок, кроме текущей, то запись непосредственно в существующую память безопасна. Первое добавление выделяет некоторый запас емкости, а последующие добавления записывают данные в этот запас. Результат? Амортизированная сложность O(1) на каждое добавление — точно так же, как работает std::vector в C++.

В чем подвох? Если ваш бинарный объект «утекает» (escapes) — то есть сохраняется в словаре процесса, возвращается вызывающей стороне или приклеивается к чему-то другому — праздник заканчивается. Вы возвращаетесь к копированию.

Этот паттерн встречается повсеместно при обработке бинарных протоколов. Когда вы итеративно строите DNS-ответы, важно, чтобы поток аккумулятора оставался «тесным».

Суб-бинарные данные: бесплатное срезание (почти)

Сопоставление (matching) в бинарных данных создает то, что BEAM называет суб-бинарными данными — крошечные термы, которые указывают на исходные данные без их копирования. Когда вы пишете:

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

Данные не копируются. Rest — это просто «окно» в исходный пакет.

Но есть нюанс, на котором многие спотыкаются: BEAM внутренне сохраняет контекст сопоставления при рекурсивном матчинге, по сути, это курсор, идущий по байтам. Он не будет материализовать суб-бинарный объект, пока вы фактически не позволите ему «утечь» — вернуть его, сохранить или передать туда, где он задержится.

Это имеет огромное значение для парсинга DNS. Каждый запрос приходит в виде бинарного блока, сопоставляется со структурой протокола и должен сгенерировать ответ. Понимание того, создаете ли вы лишнюю работу или просто просматриваете данные, — это разница между парсером, который масштабируется, и тем, который задыхается под нагрузкой.

Почему представление целых чисел важнее, чем вы думаете

В 64-битном BEAM целые числа занимают несколько бит под свой тег типа. Это оставляет 60 бит для самого значения. Целые числа, которые помещаются в это пространство, называются «малыми целыми числами» (small integers) — это немедленные значения, которые живут непосредственно в регистрах процесса, никогда не затрагивая кучу (heap).

Все, что больше, становится «большим числом» (bignum), что требует выделения памяти в куче и учета при сборке мусора. Это звучит эзотерически, но становится критичным, когда вы занимаетесь манипуляциями с битами, которых требует работа с бинарными протоколами.

Этот метод называется SWAR (SIMD Within A Register) — упаковка нескольких значений в одно целое число, чтобы вы могли оперировать ими параллельно на уровне процессора. Для DNS это означает парсинг данных объемом в несколько байт за одну операцию. Но это работает только в том случае, если ваши упакованные значения попадают в диапазон «малых целых чисел».

Если они не помещаются, вы платите не только за выделение памяти — вы потенциально запускаете циклы сборки мусора, которых иначе бы не возникло. При миллионах запросов в секунду эти циклы накапливаются.

Что это значит для вашего кода

Вот практический вывод: вам не нужно писать NIF или обращаться к C, чтобы добиться серьезного прироста производительности. Вам нужно понимать, как BEAM работает с данными.

Несколько паттернов, которые стоит усвоить:

1. Держите аккумуляторы бинарных данных «тесными». Циклы только с добавлением (append-only) — ваши друзья. Как только бинарный объект «утекает», модель затрат резко меняется.

2. Сопоставляйте на месте, когда это возможно. Используйте сопоставление с образцом (pattern matching), чтобы просматривать данные, а не копировать их. BEAM оптимизирован под это.

3. Следите за размером целых чисел. Выполняя арифметику или битовые манипуляции, думайте о том, останутся ли ваши значения в диапазоне «малых целых чисел».

4. Профилируйте с учетом редукций (reductions). BEAM планирует работу через редукции (примерно количество вызовов функций). «Горячий» цикл, который делает больше сопоставлений за меньшее количество вызовов функций, создает меньше работы с точки зрения планировщика.

Для любого, кто строит системы, обрабатывающие бинарные протоколы — будь то DNS, фреймы WebSocket или реализации кастомных протоколов — эти паттерны применимы напрямую. BEAM дает вам невероятные инструменты для написания быстрого кода, но они полезны только в том случае, если вы понимаете модель.

Мы видели, как команды тянутся к NIF на C или Rust, в то время как более глубокое понимание семантики BEAM дало бы им 90% прироста без какой-либо сложности. Среда выполнения умнее, чем принято считать — наша задача — писать код, который позволит ей проявить себя.

В NameOcean мы всегда думаем о производительности в масштабе. Запускаете ли вы Vibe Hosting для своего следующего проекта или управляете DNS для высоконагруженного приложения, понимание этих основ поможет вам строить системы, которые остаются быстрыми даже при пиковых нагрузках.

Удачного кодинга, и пусть ваши бинарные данные всегда добавляются эффективно!