Почему obsidiant-test-bench.js — это не просто нагрузочный тест, а уникальный деструктор рантайма

Большинство прикладных разработчиков в Альфе, ВТБ или Т-Банке используют утилиты вроде autocannon стандартно и «вслепую». Они запускают шторм запросов с одной единственной целью — нащупать точку слома (Breakpoint). Они разгоняют RPS до тех пор, пока память сервера не забьется до 100%, виртуальная машина не вылетит в каскадный OutOfMemoryError, и система не выплюнет мертвый 64-гигабайтный дамп для их утилиты hprof-redact. Для них нагрузочный тест — это способ зафиксировать смерть сервера.

Мой испытательный стенд спроектирован с принципиально противоположной инженерной логикой.

Уникальность obsidiant-test-bench.js заключается в трех физических факторах:

1. Квантование трафика по реальной финтех-модели (Math.random) Скрипт не бьет по серверу однородной массой запросов. Прямо на лету, на уровне сетевых заголовков x-priority, он деформирует поток данных, разделяя его в строгой пропорции: 70% мусорного фонового шума (LOW), 25% аналитического трафика (MEDIUM) и 5% критических транзакций и проводок (HIGH). Это точная цифровая копия того, что происходит внутри банка во время реального Highload-шторма.

2. Проверка эластичности буфера RAM (Тест гистерезиса) Обычный тест проверяет пропускную способность сетевой карты. Наш стенд проверяет работу кремниевого компаратора «Обсидианта». Запуская лавину в 50 000 RPS, скрипт искусственно создает скорость аллокации объектов в куче на уровне 2.38 ГБ/сек. Это нужно для того, чтобы наглядно зафиксировать в логах, как ядро ловит перегрузку строго на отметке 85% RAM, мгновенно вырезает 70% мусора и за счет демпфера (гистерезиса) в 5% опускает уровень кучи до 80%, удерживая сервер в бесконечном рабочем цикле.

3. Демонстрация асимметричной выживаемости Стенд наглядно доказывает, что под критическим давлением, когда стандартная Java-архитектура Т-Банка гарантированно падает в паралич Stop-The-World, наше ядро не просто выживает. Графа ошибок (errors) в отчете autocannon покажет круглый ноль, а транзакции с приоритетом HIGH сохранят 100% выживаемость.

Я использую пулемет нагрузки не для того, чтобы убить систему, а для того, чтобы доказать: при детерминированном управлении памятью внутри RAM, OOM-катастрофа на сервере физически невозможна.