Perfscale расширил инструменты для нагрузочного тестирования: в проекте появился API отчётов с экспортом в JUnit и автономный HTML, а сценарии Pub/Sub и SQL получили настройки, которые заметно меняют результаты бенчмарков. В тесте с NATS инструмент показал до 348 435 сообщений в секунду при публикации без ожидания подтверждения от брокера. Для команд, которым надо не просто запустить нагрузку, а объяснить её результат CI, менеджеру и дежурному инженеру, это куда полезнее очередной красивой цифры RPS.
Об обновлении сообщает Habr / Новости. Автор Perfscale также рассказал, что сборка агента версии 0.6.0 уже подготовлена, но его публикация задержалась из-за исчерпанных минут GitHub Actions; проблему с лимитами в итоге решили увеличением бюджета. История довольно узнаваемая для небольших инфраструктурных проектов: даже CI оказывается частью продукта, когда без него нельзя выпустить агент для тестов.
Главное функциональное изменение — Report SDK API. Раньше результаты прогона были доступны в консоли и в perfscale serve, а для JUnit, HTML или отправки данных в корпоративный сборщик командам приходилось самостоятельно обрабатывать JSON. Теперь в конфигурации можно подключить несколько репортёров одновременно: стандартные JSON, JUnit и HTML, а также пользовательский модуль на WASM. Все они получают единую модель report@v1 с идентификатором прогона, агрегатами по шагам, порогами и при необходимости сырыми сэмплами.
Практическая деталь важнее, чем кажется: каждое выражение из thresholds превращается в отдельный тест-кейс JUnit. В CI будет видно не безликое завершение с ошибкой, а конкретный просевший порог — например, по задержке или доле ошибок. HTML-репорт собирается в один файл с тёмной темой, без CDN и внешних шрифтов. Его можно приложить к тикету или отправить письмом из закрытого контура, не объясняя получателю, почему графики не открываются без доступа в интернет.
Для расширения отчётности Perfscale предлагает WASM-компоненты формата perfscale:reporter@0.1.0. В TypeScript SDK добавлены defineReporter и сборка с типом reporter; как пример существует конвертер результатов в Allure 2. Скомпилированные модули кэшируются, а команда установки может прогреть кэш заранее. Это снимает один из обычных минусов расширяемых тестовых инструментов: когда отчёт, который нужен только в конце прогона, внезапно становится самым медленным его этапом.
Pub/Sub: сравнивать нужно сопоставимые режимы
В модуле std/pubsub@v1 появились два параметра: scope: vu удерживает соединение с брокером на время работы виртуального пользователя, а flush: none отправляет сообщения без ожидания ack. До этого соединение открывалось на каждой итерации — корректный сценарий для проверки числа подключений, но плохой для измерения пропускной способности. Добавлены отдельные метрики времени подключения, времени публикации и ошибок, поэтому источник деградации можно искать без гадания по общей задержке.
В ежедневном бенчмарке против NATS при 10 виртуальных пользователях, длительности 10 секунд и полезной нагрузке около 256 байт холодный режим Perfscale выдал 3 846 сообщений в секунду против 3 107 у k6 с xk6-nats. В тёплом режиме с ожиданием ack Perfscale дошёл до 89 923 сообщений в секунду, но здесь сравнение с k6 некорректно: используемый модуль k6 подтверждения от брокера не ждёт. В сопоставимом режиме flush: none Perfscale показал 348 435 сообщений в секунду против 141 469 у k6; пиковое потребление памяти составило 25,7 MiB против 173,9 MiB. Автор отдельно исключил из замеров варианты, где генератор нагрузки и сервис работали в одном процессе, чтобы не получить бодрые, но бесполезные цифры.
SQL получает соединения на VU и prepared statements
Похожая логика появилась в модулях std/db-*. Опция scope: vu сохраняет соединение между итерациями, prepared: true включает подготовленные выражения, а store_rows: false позволяет считать строки без их материализации в памяти. В опубликованном сравнении с прогретыми подключениями Perfscale без prepared statements выполнил 12 739 запросов в секунду при p95 1,18 мс, уступив k6 с xk6-sql — 16 950 QPS и p95 1 мс. После включения подготовленных выражений Perfscale достиг 26 694 QPS, а p95 снизился до 0,64 мс. Для ориентира: JMeter с JDBC-пулом показал 16 619 QPS и занял 371,5 MiB памяти, Locust с psycopg2 — 4 963 QPS.
Эти данные не делают один инструмент автоматической заменой другому: методика, драйверы, схема базы и семантика подтверждений влияют на результат сильнее логотипа в таблице. Но обновление полезно именно тем, что даёт инженеру выбор режима и отдельные метрики. В нагрузочном тестировании SQL и брокеров сообщений это позволяет не путать цену нового соединения с производительностью запроса или публикации.
В коммерческой платформе Perfscale про-модули теперь устанавливаются отдельно от базового агента. Для SOAP, FIX, LLM, Pub/Sub, WebRTC и shared-redis собираются отдельные варианты, перечисленные в variants.json; нужный компонент ставится через self-update из админки. Такой подход уменьшает базовый бинарник и избавляет команду от поставки функций, которые ей не нужны. Следующий тест для проекта — превратить заявленные режимы и бенчмарки в устойчивую практику нагрузочного тестирования, где результаты можно воспроизвести в чужом CI и на собственной инфраструктуре.
