Perfscale News №14: нагрузочное тестирование WebRTC, исправление FIX и новый API reference
В четырнадцатом выпуске новостей Perfscale - поддержка WebRTC, исправление интеграции с FIX и обновлённая документация API. Также команда доработала SDK для авторов библиотек и сделала описание метрик более подробным.
SDK библиотек: пример на Go и WIT 0.2.0
В SDK появился пример библиотеки на Go, подготовленный для TinyGo 0.42 и Go 1.25+. Одновременно интерфейс обновили до WIT 0.2.0: теперь настройки библиотеки передаются непосредственно в контексте `Ctx`.
Изменилось и требование к возможностям библиотек. Поле `capabilities` необходимо указывать явно - допустимо передать и пустой список `[]`. Если этого не сделать, сценарий не пройдёт проверку. Раньше отсутствие поля могло оставаться незамеченным, а проблемы проявлялись уже позднее. Теперь ошибку проще обнаружить при lint-проверке, до запуска в рабочей среде.
Документация метрик стала подробнее
Разделы о метриках переработали: теперь каждая метрика описана отдельно, с пояснениями, где и при каких условиях она собирается. Это помогает точнее понимать результаты нагрузочного теста и сопоставлять показатели разных компонентов.
Отдельно разъяснена логика метрик с суффиксом `failed`. Они формируются на основе сэмплов со значениями 0 и 1, из которых рассчитывается частота ошибок. Для фоновых сэмплеров такой показатель не используется: у них нет отдельного вызова, который можно было бы считать успешным или неуспешным.
WebRTC: тестирование полного медиасценария
В Perfscale появилась возможность проводить нагрузочные тесты WebRTC с прохождением настоящего медиатракта. Каждый виртуальный пользователь участвует в установлении соединения, а затем тест выполняется уже на готовом канале.
Это важно не только для проверки качества звонка. Даже если после подключения медиа передаётся напрямую между пользователями, инфраструктуре всё равно нужно найти участников, помочь им пройти NAT и сетевые ограничения, обменяться параметрами соединения и корректно обработать завершение звонка. Нагрузка возникает на разных этапах жизненного цикла - от сигнализации до закрытия соединения.
В базовом сценарии виртуальные пользователи объединяются в пары с помощью shared variables: тысяча VU моделирует 500 одновременных звонков. Затем стороны обмениваются SDP и проходят этапы ICE и DTLS-SRTP. После установления соединения тестируются публикация и получение аудио- и видеодорожек. В примере используются аудио и видео 320×240 с частотой 15 кадров в секунду.
Далее звонок некоторое время остаётся активным, после чего Perfscale собирает статистику и закрывает соединение. Поддержка доступна в агенте `perfscaled` версии 0.4.0 для пользователей тарифов Pro и Enterprise.
Параметр `hold` задаёт продолжительность одного звонка внутри итерации. Например, при `hold: 30s` и общей длительности теста `duration: 10m` каждая пара успеет совершить примерно двадцать звонков. При 500 одновременно активных парах это около десяти тысяч звонков за весь прогон. Если нужны долгие соединения без повторных вызовов, значение `hold` стоит приблизить к общей продолжительности теста.
Если число виртуальных пользователей нечётное, одному VU не достанется партнёр. Он попытается отправить предложение, а затем завершит попытку по таймауту. Это ожидаемое поведение: пары для него нет. Поэтому порог для `webrtc_call_errors_signaling` в таком сценарии должен допускать небольшое число ошибок, а не требовать строго нулевого значения.
При планировании теста важно учитывать и затраты ресурсов. Пятьсот пар означают тысячу DTLS-стеков и две тысячи RTP-потоков. Кодек VP8 обычно не создаёт чрезмерной нагрузки на процессор, тогда как AV1 требует значительно больше вычислений. Для кодирования каждого видеотрека может понадобиться около одного ядра. Поэтому запускать сотни пар с AV1 на неподготовленной инфраструктуре не стоит: разумнее использовать VP8 либо уменьшить число виртуальных пользователей.
FIX: исправление интеграции
В предыдущей реализации шаги `pro/fix*` уже существовали, однако не были подключены в агенте `perfscaled`. В итоге код был написан, но выполнить нужный сценарий через агент было нельзя. В этом выпуске интеграцию поправили: FIX-шаги подключены к агенту и доступны для использования в тестах.
Это особенно важно для команд, которые проверяют системы с финансовыми и биржевыми протоколами. При нагрузочном тестировании здесь недостаточно просто увеличить число запросов: нужно воспроизводить обмен сообщениями в предусмотренном протоколом формате и наблюдать за поведением всей цепочки обработки.
Новый API reference
В Perfscale также подготовили полностью обновлённый API reference. Справочник призван упростить работу с интерфейсами платформы: в нём можно ориентироваться по доступным сущностям и параметрам, не ограничиваясь общими описаниями возможностей продукта.
Практическая ценность API-документации особенно заметна при автоматизации тестов. Командам проще связывать нагрузочные проверки с собственными процессами развёртывания, управлять сценариями программно и разбираться в поведении интеграций. Чем точнее описаны методы и их параметры, тем меньше времени уходит на подбор настроек и поиск причин некорректных запросов.
Что учесть перед запуском теста
Перед WebRTC-прогоном полезно заранее определить целевые значения одновременных звонков, длительность соединения и кодек. Эти параметры непосредственно влияют на число сессий, продолжительность теста и загрузку CPU. Начинать лучше с небольшой конфигурации и постепенно повышать нагрузку, контролируя показатели агента и медиасервера.
Также стоит отделять ошибки, которые действительно указывают на проблему инфраструктуры, от ожидаемых особенностей сценария. Например, при нечётном количестве VU один участник остаётся без пары - и соответствующая ошибка сигнализации сама по себе не свидетельствует о неисправности сервиса.
В совокупности обновления выпуска затрагивают сразу несколько этапов работы с Perfscale: создание библиотек, чтение результатов нагрузочного теста, настройку API-интеграций и проверку сложных сценариев связи. Наиболее заметное нововведение - WebRTC-тестирование полного пути звонка, позволяющее оценивать не только передачу медиа, но и подготовку соединения, его поддержание и корректное завершение.
