Сколько RTSP камер можно подключить к WebRTC серверу?

С системами видеонаблюдения мы сталкиваемся в самых разных местах — это магазины, торговые центры, банки, гостиницы, здания офисов, коттеджи и квартиры, автостоянки и оживлённые перекрёстки — трудно перечислить все возможные варианты установки камер. Так же существует великое множество различных аппаратных и программных решений по организации видеонаблюдения: аналоговые камеры и «железные» регистраторы всех сортов и расцветок, софтовые решения, облачные решения, IP камеры, которые могут работать как сами по себе, так и с серверными или софтовыми решениями и т.п. Из всего многообразия нас будут интересовать те экземпляры, которые отдают видеопотоки по протоколу RTSP.

В одной из предыдущих статей мы уже обсуждали, как добавить видео с IP камеры на свой сайт. Например, система видеонаблюдения за подъездами нескольких домов, относящихся к одной управляющей компании. Нужно реализовать возможность просмотра происходящего в реальном времени на сайте управляющей компании. Как вы знаете, браузеры не умеют играть RTSP потоки напрямую, поэтому, в этом случае, нужно превратить RTSP видеопоток от IP камеры в WebRTC, который успешно обрабатывается браузером и выдает самую низкую задержку при воспроизведении — менее 0.5 секунды. Это можно сделать при помощи Web Call Server — сервера обработки потокового видео для Web-проектов.

schema_RTSP_testing_VOD_WCS__RESTApi_stream_publishing_IPcamera_browser

И если с программной реализацией все более-менее понятно из статьи, то на этапе внедрения решения обязательно появится вопрос:

«Какой нам нужен сервер и сколько камер мы сможем к нему подключить?»

Эта статья продолжает цикл статей по нагрузочным тестам. Сегодня мы разберем методику тестирования и ответим на вопрос «Сколько IP камер можно подключить к WCS?»

Приступим.

План тестирования

schema_test_RTSP_testing_VOD_WCS__RESTApi_stream_publishing_IPcamera_browser

Опубликовать VOD поток на сервере WCS#1.
С помощью скрипта, использующего REST запросы, опубликовать RTSP потоки на сервере WCS#2.
Выбрать случайный RTSP стрим на WCS#2 и визуально оценить качество потока.
Оценить нагрузку на сервер WCS#2 по значениям метрик, собираемых системой мониторинга Prometheus для сервера WCS#2.

Тестирование будем считать успешным, если удастся подключить 1000 IP камер и не будет зафиксировано деградации потоков в результатах мониторинга или визуально.

Подготовка к тестированию

Для тестирования нам понадобятся

два WCS-сервера;
скрипт для проведения теста.

Предполагаем, что у вас уже есть установленные и настроенные серверы WCS. Если нет, то устанавливаем по этой инструкции, делаем твики для производительности и подключаем к мониторингу.

Для тестирования мы использовали два сервера:

WCS#1 (тестирующий) с характеристиками:

24 ядра, 48 потоков;
128 Gb RAM;
WCS 5.2.958;
OpenJDK version 14.0.1

WCS#2 (тестируемый) с характеристиками:

12 ядер, 24 потока;
96 Gb RAM;
WCS 5.2.958;
OpenJDK version 14.0.1

Настройки серверов

Файл flashphoner.properties (без настроек по умолчанию):

#webrtc ports range
media_port_from = 20001
media_port_to = 40000

#websocket ports
ws.port =8080
wss.port =8443

rtsp_activity_timer_timeout=86400000

wcs_agent_port_from=44001
wcs_agent_port_to=55000

global_bandwidth_check_enabled=true
zgc_log_parser_enable=true
zgc_log_time_format=yyyy-MM-dd'T'HH:mm:ss.SSSZ

rtsp_port_from=55001
rtsp_port_to=65000

Здесь мы увеличили диапазон портов для WebRTC, RTSP и WCS агента. Увеличили таймаут для RTSP потоков без подписчиков, а также указали настройки для сбора дополнительных метрик по загруженности сети и пауз в работе ZGC.

Для тестирующего сервера добавили дополнительные настройки для VOD — циклический захват потока и настройка продолжительности публикации VOD потока после отключения подписчиков:

vod_live_loop=true
vod_stream_timeout=14400000

Файл wcs-core.properties (без настроек по умолчанию):

-XX:ErrorFile=/usr/local/FlashphonerWebCallServer/logs/error%p.log

# ZGC
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms24g -Xmx24g -XX:+UseLargePages -XX:ZPath=/hugepages

-Xlog:gc*:/usr/local/FlashphonerWebCallServer/logs/gc-core-:time

Здесь мы изменили настройки для именования файлов логов, включили использование ZGC, настроили размер Heap и включили использование страниц памяти.

Полные версии файлов настроек можно скачать в разделе «Полезные файлы» в нижней части статьи. Там же вы найдете панель для Grafana и файл скрипта для запуска тестирования.

Скрипт для тестирования

#! /bin/bash
camera=1000

curl -X POST -H 'Content-type: application/json' --data "{\"uri\":\"vod-live://bunny720p-test.mp4\", \"localStreamName\":\"test\"}" "http://localhost:8081/rest-api/vod/startup"
sleep 5s

for i in `seq 1 $camera`; do
curl --data "{\"uri\":\"rtsp://172.16.40.2:554/test?"$i"\",\"toStream\":\"RTSP-test-stream"$i"\"}" -X POST -H 'Content-type: application/json' -s http://172.16.40.3:8081/rest-api/rtsp/startup
sleep 0.1s
done

где:

camera — количество эмулируемых RTSP потоков.

В тестах мы будем использовать видеоролик с разрешением 720р. Подробнее параметры ролика на скриншоте ниже:

Тестирование

На тестирующем сервере WCS#1 запускаем скрипт для тестирования:

./RTSP-load-test.sh

Результат тестирования для 1000 захваченных RTSP потоков:

Тест был пройден успешно. По метрикам деградация стримов не была зафиксирована. Загрузка CPU по метрике Load average 1 не превысила 100 единиц.

Открываем на тестируемом сервере WCS#2 стандартный пример «Player» и запускам воспроизведение случайного RTSP потока из захваченных:

control_stream_RTSP_testing_VOD_WCS__RESTApi_stream_publishing_IPcamera_browser

Контрольный поток воспроизводится с приемлемым качеством — без фризов, артефактов и снижения качества звука.

Мы провели еще несколько тестов

для 1500 RTSP потоков:

и для 2000 RTSP потоков:

По результатам этих тестов мы наблюдаем увеличение нагрузки на CPU и увеличение пауз в работе ZGC. По метрикам деградация стримов не фиксируется, но контрольный поток воспроизводится с заметными артефактами.

control_stream_2000_RTSP_testing_VOD_WCS__RESTApi_stream_publishing_IPcamera_browser

Как вы могли заметить, тесты не отличались большой продолжительностью. Поэтому принимать решение по выбору сервера для системы видеонаблюдения на их основе было бы не совсем правильно. Ведь в долгосрочной перспективе поведение системы может измениться.

Проведем еще один тест с тысячей захваченных RTSP потоков:

Этот тест продолжался без малого два часа. За это время можно увидеть, что критических изменений по загруженности ресурсов не наблюдается. Контрольный поток тоже все время воспроизводился корректно:

control_stream_long_test_RTSP_testing_VOD_WCS__RESTApi_stream_publishing_IPcamera_browser

Напоминаем, что результаты тестирования напрямую зависят от окружения, поэтому могут отличаться как в лучшую, так и в худшую сторону при тестировании на вашем оборудовании.

Хорошего стриминга!