Open-source инструмент Perfscale поднял заявленную производительность записи метрик с 14,7 млн до 118,6 млн операций в секунду на 16 потоках. Для команд, которые используют нагрузочное тестирование Perfscale, это не косметическое ускорение: сбор статистики реже станет ограничением самого генератора нагрузки, когда сценарий уже упирается в сеть, базу данных или тестируемый сервис.
Изменения вошли в очередной выпуск проекта, сообщает Habr / Новости. Главная техническая переделка — переход хранилища метрик на шардированную структуру ShardedMetrics: вместо единого разделяемого объекта разработчики используют набор шардов. Такой подход уменьшает конкуренцию потоков за общие данные и позволяет задействовать вычислительные ресурсы параллельно. Авторы связывают рост пропускной способности именно с тем, что все потоки теперь получают полезную работу, а не ждут доступа к общей структуре.
Цифра в 118,6 млн ops/s выглядит впечатляюще, но не отменяет более приземлённых лимитов. При интенсивных тестах пользователь всё ещё может упереться в системный предел открытых файлов, количество сокетов и состояние портов. Иными словами, быстрый сбор метрик не превратит машину с консервативным ulimit в лабораторию для бесконечной нагрузки. Командам стоит проверять настройки ОС, лимиты контейнеров и параметры сетевого стека одновременно с обновлением инструмента.
Вместе с оптимизацией ядра разработчики расширили команду perfscale serve. При запуске локального сервера в браузере теперь доступна офлайн-документация на русском и английском языках. Для корпоративной среды с изолированными контурами это полезнее, чем кажется: инженер может свериться со справкой прямо рядом с интерфейсом, не открывая внешнюю документацию и не обходя ограничения доступа в сети.
Отдельно обновлён ежедневный bench-профиль, в котором Perfscale сравнивают с Locust, k6 и JMeter на нескольких сценариях. В набор добавили SQL-проверки и замеры для k6, причём речь идёт не о стандартной сборке k6, а о кастомном бинарнике xk6-sql с драйвером PostgreSQL. Это важная оговорка для тех, кто будет смотреть на таблицы результатов: сравниваются не абстрактные «бренды» инструментов, а конкретные конфигурации и модели работы с подключениями.
Сценарии тоже различаются. Для Perfscale тестируются холодные подключения с запросом SELECT 1 на итерацию, вариант с параметром, постоянный пул и транзакционный режим. У конкурентов воспроизводится близкая «тёплая» схема: Locust держит подключение на пользователя, JMeter использует JDBC-пул, а xk6-sql — одно подключение на виртуального пользователя. Поэтому результаты полезны прежде всего как контроль регрессий самого проекта и ориентир по поведению в заданной среде, а не как универсальный рейтинг для любой базы и любого продакшена.
В релиз также вошли менее заметные, но практичные изменения. Появилась команда очистки кэша скачанных модулей perfscale cache clean. Самообновление стало интерактивным, получило повторные попытки для медленных сетей и флаг неинтерактивного запуска для CI. Dev-сборки теперь помечаются форматом 0.25.0-next.N+g, чтобы версию экспериментального бинарника было проще распознать по выводу команды. В GitHub Action, GitLab CI и Helm-чартах проверка контрольных сумм стала строгой: то, что раньше давало предупреждение, теперь должно останавливать процесс.
Ещё одна деталь касается состава продукта. JavaScript SDK архивирован из-за отсутствия использования, а расширения перенесены в sdk-libraries и WASM-модули. Параллельно команда готовит каталог для коммерческих модулей — SQL, SOAP, FIX, LLM и PubSub. Идея в том, чтобы включать в итоговый бинарник только те компоненты, которые нужны конкретному сценарию. Это удерживает размер поставки, но добавляет этап сборки непосредственно перед запуском теста. Для DevOps-пайплайна такая схема потребует аккуратного кеширования и воспроизводимых зависимостей.
Нагрузочное тестирование Perfscale всё больше смещается от одного CLI-инструмента к набору компонентов с локальной документацией, модульной поставкой и строгой проверкой артефактов. Следующий практический вопрос — сохранится ли заявленная скорость метрик в реальных смешанных сценариях, где одновременно работают HTTP, базы данных, очереди и пользовательские расширения. Именно там оптимизация внутреннего счётчика должна доказать, что она ускоряет не только синтетический бенчмарк.