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

Зачем подключать IP камеры к серверу? Например, для того, что бы сделать простую систему видеонаблюдения, которая транслирует происходящее перед камерами на сайт. Из всего многообразия IP камер нас интересуют те экземпляры, которые отдают видеопотоки по протоколу RTSP. Дело в том, что браузеры не умеют играть RTSP потоки напрямую, поэтому, чтобы добавить видео с IP камеры на свой сайт нужно превратить RTSP видеопоток от IP камеры в WebRTC. И если с программной реализацией все более-менее понятно из статьи, то на этапе внедрения решения обязательно появится вопрос:

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

Приступим.

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

  1. Опубликовать VOD поток на сервере WCS#1;

  2. С помощью скрипта, использующего REST запросы, опубликовать RTSP потоки на сервере WCS#2;

  3. Выбрать случайный RTSP стрим на WCS#2 и визуально оценить качество потока;

  4. Оценить нагрузку на сервер 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 потока из захваченных:

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

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

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

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

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

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

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

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

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

Полезные файлы

Панель для Grafana:

RTSP-720p-testing.json

Настройки WCS:

flashphoner.properties

wcs-core.properties

Скрипт для теста:

RTSP-load-test.sh

Ссылки

Наш демо сервер

WCS на Amazon EC2 - Быстрое развертывание WCS на базе Amazon

WCS на DigitalOcean - Быстрое развертывание WCS на базе DigitalOcean

WCS в Docker - Запуск WCS как Docker контейнера

HTML5-трансляции с RTSP-IP камер - Функции сервера по воспроизведению RTSP видеопотоков

Документация по быстрому развертыванию и тестированию WCS сервера

Документация по мониторингу информации о нагрузке и ресурсах

Документация по организации мониторинга с помощью Prometheus

Описание файла настроек flashphoner.properties

Описание файла настроек wcs-core.properties

Документация по управлению памятью в Java

Рекомендации по тонкой настройке сервера

Документация по подготовке к промышленной эксплуатации WCS

Комментарии (6)


  1. Girafa01
    06.09.2021 11:38

    В статье нет основных критериев для выбора сервера: объем ресурсов сервера выделяемых на один поток. Без этого проведенные испытания: ну было и было...


    1. fpn Автор
      06.09.2021 11:52

      Дело в том, что этот объем можно определить исключительно опытным путем, т.к. потребление ресурсов в зависимости от количества публикаций и количества подписчиков на каждый из опубликованных потоков растет нелинейно. Без транскодинга видео (то есть опубликовали H264 и забрали H264 в том же разрешении) будет транскодироваться только звук, если он есть в потоке, и если камера отдает звук не в PCMA/PCMU и Opus, но основную нагрузку при использовании WebRTC дает шифрование трафика.

      Для простоты можно считать, что минимально рекомендуемая конфигурация (1 CPU, 2 Гб RAM, из них 1 Гб Java heap) гарантированно способна принять один RTSP поток и отдать его одному подписчику.


  1. denaspireone
    06.09.2021 12:57

    Вам бы доку обновить по node_exporter-у https://docs.flashphoner.com/pages/viewpage.action?pageId=14256163
    И я вам помогу с этим https://gist.github.com/denisgolius/f9bebf21dd126391effab9fb5a992388 то, чем пользуюсь я, но некоторые флаги возможно лишние конечно.

    Еще я бы советовал попробовать victoriametrics single инстанс которой может в разы больше, чем пара prometheus инсталяций. Если есть вопросы - добро пожаловать в сообществов Телеграме t.me/VictoriaMetrics_ru1 или Slack slack.victoriametrics.com .


    1. fpn Автор
      07.09.2021 06:20

      Вам бы доку обновить по node_exporter-у https://docs.flashphoner.com/pages/viewpage.action?pageId=14256163И я вам помогу с этим https://gist.github.com/denisgolius/f9bebf21dd126391effab9fb5a992388 то, чем пользуюсь я, но некоторые флаги возможно лишние конечно.

      Не видно принципиальной разницы, кроме версии (которая в документации приведена для примера) и явного перечисления флагов (которые и так включены по умолчанию https://github.com/prometheus/node_exporter#enabled-by-default)

      Еще я бы советовал попробовать victoriametrics single инстанс которой может в разы больше, чем пара prometheus инсталяций

      Поскольку этот инструмент декларирует совместимость с форматом Prometheus, со сбором метрик WCS не должно быть явных проблем


      1. denaspireone
        07.09.2021 06:34

        Разница немного есть, вы выполняете вставку каждой строки равную кол-ву строк, вместо ввода весрии и выполнения 4х вставок, но результат да, будет поидее таким же.


        1. fpn Автор
          07.09.2021 06:51

          Ваш вариант немного более читабелен, да. Поправили, заодно добавили sudo там, где его не хватало