Perfscale добавил нагрузочное тестирование WebRTC и обновил API reference

В новом выпуске Perfscale разработчики представили сразу несколько заметных изменений: нагрузочное тестирование WebRTC через настоящий медиапуть, полностью переработанный API reference, обновления SDK и исправление интеграции FIX в агенте. Также команда подробно переписала документацию по метрикам и перенесла проверку сценариев на этап их сохранения.

Обновления SDK и документации

В SDK появился пример на Go, совместимый с TinyGo 0.42 и Go 1.25+. Интерфейс обновили до WIT 0.2.0: теперь настройки библиотеки передаются непосредственно в контексте Ctx.

Для авторов библиотек capabilities стали обязательными. Сценарий без явно указанного поля, включая пустой список [], теперь не проходит валидацию. Раньше такие сценарии могли молча работать, из-за чего ошибка обнаруживалась уже позднее. Разработчики объясняют изменение стремлением выявлять проблемы на этапе lint, а не во время выполнения в продакшене.

Разделы Metrics в документации переработали полностью. Каждая метрика теперь сопровождается описанием условий и места сбора. Отдельно объясняется работа failed-метрик: из последовательности сэмплов 0/1 формируется rate, однако у фоновых сэмплеров такого показателя нет, поскольку отсутствует отдельный вызов, который мог бы завершиться ошибкой.

Нагрузочные тесты WebRTC

В агенте perfscaled 0.4.0 появилась поддержка нагрузочного тестирования WebRTC через настоящий медиапуть. Каждый виртуальный пользователь выполняет рукопожатие и запускает тест на готовом соединении. Функция доступна пользователям тарифов Pro и Enterprise.

В базовом сценарии пары создаются через shared variables: 1000 VU формируют 500 одновременных звонков. Затем стороны проходят этапы ICE и DTLS, обмениваются SDP, публикуют и принимают аудио- и видеотреки. В тесте используются потоки 320×240 с частотой 15 кадров в секунду. После этого звонок некоторое время находится в состоянии hold, затем система собирает статистику и закрывает соединение.

Параметр hold: 30s задаёт длительность одного звонка внутри итерации. При общей продолжительности теста 10 минут каждая пара совершит примерно 20 звонков, то есть при 500 одновременных соединениях суммарно получится около 10 тысяч звонков. Чтобы получить длинные звонки без повторных вызовов, значение hold следует приблизить к duration.

Нечётное число VU оставляет одного пользователя без пары. Такой VU пытается создать оффер и завершается по таймауту, увеличивая счётчик webrtc_call_errors_signaling. Это ожидаемое поведение, поэтому в примере порог задан как count < 10, а не как строгое равенство нулю.

Нагрузка на инфраструктуру зависит от кодека. Для 500 пар требуется около 1000 DTLS-стеков и 2000 RTP-потоков. VP8 почти не нагружает процессор, тогда как AV1 может потребовать примерно одно ядро на каждый кодируемый трек. Для конфигурации с 1000 VU это теоретически означает около 1000 ядер, поэтому разработчики рекомендуют использовать VP8 либо уменьшать число виртуальных пользователей при выборе AV1.

FIX, API и исправления

В предыдущей версии шаги pro/fix были реализованы, но не зарегистрированы в агенте perfscaled. В релизе 0.4.0 FIX подключили вместе с остальными pro-возможностями, а для защиты от повторения проблемы добавили новый end-to-end-тест.

Controlplane теперь самостоятельно генерирует OpenAPI. Страница API reference получила интерактивный интерфейс Swagger UI с функцией Try it out, а спецификацию можно скачать. В документации описан ответ 402 Payment Required, поскольку API доступен только после оплаты. Из примеров убрали localhost и добавили рабочие URL, а сам справочник получил поддержку локализации.

Проверка сценария теперь выполняется при сохранении теста: некорректный запрос сразу возвращает ошибку 422, вместо того чтобы проблема обнаруживалась уже на агенте во время запуска. Кроме того, исправили тёмную тему документации: компонент Scalar ранее переопределял фон глобальным стилем, из-за чего интерфейс становился плохо читаемым ночью.

Сбой GitHub Actions

Вечером 5 октября 2026 года hosted-раннеры GitHub Actions перестали выдаваться. Задания деплоя завершались примерно через 15 минут, не успев выполнить первый шаг, с сообщением «job was not acquired by Runner». Конфигурация Perfscale не была причиной сбоя: проблему удавалось обходить ожиданием и повторным запуском заданий.