В агенте perfscaled 0.4.0 появилось нагрузочное тестирование WebRTC: 1000 виртуальных пользователей могут создать 500 одновременных звонков, пройти ICE и DTLS-SRTP, передавать аудио и видео, а затем собрать статистику соединений. Для команд, которые развивают звонки, видеоподдержку или коммуникационные платформы, это означает возможность проверять не только HTTP-ручки вокруг сервиса, но и сам жизненный цикл медиасессии.
О выпуске сообщает Habr / Новости. Помимо WebRTC, разработчики Perfscale исправили неприятную ошибку с протоколом FIX: готовые pro/fix-шаги существовали в коде, но не были зарегистрированы в агенте. Также платформа получила переработанный справочник API с интерактивной проверкой запросов и более подробное описание метрик.
Новый сценарий WebRTC покрывает последовательность, которая обычно и ломается под реальной нагрузкой: пользователи объединяются в пары, обмениваются SDP, проходят проверки ICE и рукопожатие DTLS-SRTP, публикуют и получают медиатрeки, удерживают звонок заданное время, после чего соединение закрывается. Для пар между несколькими агентами предлагается Redis; если все виртуальные пользователи работают в одном процессе, достаточно памяти процесса. При 1000 VU стратегия adjacent формирует 500 пар — то есть 500 параллельных звонков.
В базовом примере каждая сторона отправляет и принимает синтетические аудио- и видеоданные: Opus с битрейтом 64 кбит/с и VP8 в разрешении 320×240 при 15 кадрах в секунду. В конфигурации можно указать собственный TURN-сервер, чтобы тестировать не только прямые соединения в одном контуре, но и прохождение NAT, работу relay-инфраструктуры и сигналинг. Это важная деталь: WebRTC называют peer-to-peer, но до передачи медиа сервису ещё нужно найти клиентов, согласовать параметры, провести их через сетевые ограничения и корректно обработать отключение каждой стороны.
Авторы отдельно предупреждают о цене реалистичности. Конфигурация на 500 пар означает 1000 DTLS-стеков и 2000 RTP-потоков. VP8 в таком сценарии почти не нагружает процессор, тогда как AV1 требует существенно больше ресурсов: ориентир — около одного ядра на каждый кодируемый трек. Для тысячи VU это может превратиться примерно в тысячу ядер, поэтому тест с AV1 разумнее начинать с меньшего числа пользователей. Не менее легко получить ложную тревогу из-за нечётного числа VU: последний пользователь останется без пары, дождётся таймаута сигналинга, и такой результат для этой схемы считается ожидаемым.
Практический смысл нагрузочного тестирования WebRTC — в измерении стадий, а не в одном усреднённом времени ответа. В сценарии можно задать пороги для времени установления звонка, ошибок сигналинга, проблем ICE и DTLS, а также для потерь пакетов, джиттера и раунд-трип задержки. Если удерживать соединение 30 секунд при общем тесте на 10 минут, каждая пара будет перезванивать примерно 20 раз: получится около 10 тысяч звонков при стабильных 500 одновременных. Для проверки долгих конференций, напротив, время удержания стоит приблизить к длительности прогона.
Исправление FIX выглядит скромнее, но для финансовых и трейдинговых систем оно не менее полезно. Ошибка была классической: реализация шагов была готова, однако агент не подключал её через регистрацию. В версии 0.4.0 pro/fix-семейство добавили в агент и закрепили отдельным сквозным тестом. Это снижает риск ситуации, когда сценарий проходит проверку или выглядит доступным в документации, но не исполняется в рабочем окружении.
Ещё одно изменение касается SDK для авторов библиотек. Интерфейс обновили до WIT 0.2.0, а настройки библиотеки теперь передаются через контекст. Поле capabilities стало обязательным: даже сценарий без возможностей должен явно передать пустой список. Раньше отсутствие поля принималось молча, что могло проявиться уже после публикации сценария. Для разработчиков расширений это менее комфортно на старте, зато ошибки конфигурации ловятся на валидации, а не в нагрузочном прогоне.
Наконец, Controlplane теперь генерирует спецификацию OpenAPI, а справочник API получил интерактивный режим проверки запросов и возможность скачать спецификацию. Документация метрик тоже стала детальнее: каждая метрика описана отдельно, включая логику расчёта failed-rate из сэмплов 0/1 и ограничение фоновых сборщиков, у которых нет отдельного вызова, способного завершиться ошибкой. Для команды эксплуатации это полезнее красивого дашборда: проще понять, что именно измеряется и где искать источник деградации.
Perfscale делает ставку на всё более прикладные сценарии нагрузки: после HTTP, WebSocket, gRPC, SQL и GraphQL в набор вошёл медиа-трафик. Главный вопрос теперь не в том, можно ли сгенерировать тысячу звонков, а в том, насколько команды будут готовы сопоставлять результаты нагрузочного тестирования WebRTC с реальной сетью пользователей, TURN-релеями и поведением мобильных клиентов.