Мы продолжаем разбирать варианты нагрузочных тестов. В этой статье мы разберем методику тестирования и проведем нагрузочный тест, с помощью которого попытаемся определить число пользователей, которые одновременно будут и зрителями, и стримерами, т.е. каждый пользователь и публикует, и просматривает потоки.
Один из самых распространённых вариантов работы WebRTC сервера это "Один ко многим". В этом варианте к серверу подключается много зрителей, которые смотрят один поток. Таким образом работает, например, трансляция соревнований: трансляция идет, зрители смотрят.
Но случается, что нужно реализовать другой подход - "Один к одному", когда стример является зрителем другого потока Такой вариант может использоваться, например, для организации видеочата без использования микшера или MCU.
План-схема тестирования
На тестирующем сервере WCS#1 опубликовать поток 1280x720, 30 fps, битрейт 2500 кбит/с.
Опубликовать исходный поток, при помощи REST API запроса /pull/push, в необходимом количестве экземпляров на тестируемый сервер WCS #2.
При помощи второго REST API запроса /pull/push забрать с тестируемого сервера WCS#2 на сервер WCS#1 каждый экземпляр ранее опубликованного потока.
На тестируемом сервере WCS#2 воспроизвести случайный поток и визуально оценить его качество. Оценить нагрузку на сервер с помощью метрик, получаемых от системы мониторинга Prometheus.
Тестовый стенд
Для тестирования нам понадобятся
два WCS-сервера;
стандартный пример "Media Devices" для публикации потока с заданными параметрами;
скрипт для проведения теста;
Предполагаем, что у вас уже есть установленные и настроенные серверы WCS. Если нет, то устанавливаем по этой инструкции, делаем твики для производительности и подключаем к мониторингу.
Для тестирования мы использовали два сервера:
WCS#1 (тестирующий) с характеристиками:
24 ядра, 48 потоков
128 Gb RAM
WCS 5.2.946
OpenJDK version 14.0.1
и
WCS#2 (тестируемый) с характеристиками:
12 ядер, 24 потока
84 Gb RAM
WCS 5.2.946
OpenJDK version 14.0.1
В одном из предыдущих тестирований мы опытным путем уже выяснили, что нагрузка на тестирующий сервер приходится достаточно большая, поэтому для успешности тестов тестирующий сервер должен быть минимум в два раза мощнее, чем тестируемый, или в качестве тестирующего должно выступать несколько серверов.
Настройки наших серверов:
Файл flashphoner.properties (без настроек по умолчанию):
#webrtc ports range
media_port_from = 20001
media_port_to = 40000
wcs_activity_timer_timeout=86400000
global_bandwidth_check_enabled=true
zgc_log_parser_enable=true
zgc_log_time_format=yyyy-MM-dd'T'HH:mm:ss.SSSZ
Здесь мы увеличили диапазон портов и время на прохождение теста, а так же указали настройки для сбора дополнительных метрик по загруженности сети и пауз в работе ZGC.
Файл 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
sourceStreamName=$1
sourceServer=$2
serverToTest=$3
testStreamsCount=$4
if [[ -z $sourceStreamName ]] || [[ -z $sourceServer ]] || [[ -z $serverToTest ]]; then
echo "Usage: $(basename $0) stream_name source_server server_to_test test_streams_count"
echo -e " stream_name\t\tstream published on source server name"
echo -e " source_server\t\tsource server ip address"
echo -e " server_to_test\t\tserver to test ip address"
echo -e " test_streams_count\t\tstreams count to push (1 by default)"
exit 1
fi
[[ -z $testStreamsCount ]] && testStreamsCount=1
# Check if source stream is published
result=`curl -s -i -o /dev/null -w '%{http_code}' -H "Content-Type: application/json" -X POST http://$sourceServer:8081/rest-api/stream/find --data "{\"name\":\"$sourceStreamName\",\"published\":true}" | grep 200`
if [[ $result != "200" ]]; then
echo "Stream $sourceStreamName is not published on server $sourceServer!"
exit 1
fi
# Push streams to the server to test
echo "Publishing $testStreamsCount copies of stream $sourceStreamName to the server $serverToTest"
for ((i = 1; i <= $testStreamsCount; i++)); do
curl -s -H "Content-Type: application/json" -X POST http://$sourceServer:8081/rest-api/pull/push --data "{\"uri\":\"ws://$serverToTest:8080/websocket\",\"localStreamName\":\"$sourceStreamName\",\"remoteStreamName\":\"$sourceStreamName$i\"}"
done
# Wait for 5 seconds
echo "Waiting for 5 seconds..."
sleep 5
# Push streams back to source server
echo "Playing $testStreamsCount copies of stream $sourceStreamName from the server $serverToTest"
for ((i = 1; i <= $testStreamsCount; i++)); do
curl -s -H "Content-Type: application/json" -X POST http://$serverToTest:8081/rest-api/pull/push --data "{\"uri\":\"ws://$sourceServer:8080/websocket\",\"localStreamName\":\"$sourceStreamName$i\",\"remoteStreamName\":\"$sourceStreamName$i\"}"
done
echo "To stop the test, just stop publishing stream $sourceStreamName"
где:
sourceStreamName — имя исходного потока, который опубликован на тестирующем сервере WCS#1;
sourceServer — имя или IP адрес тестирующего сервера WCS#1;
serverToTest — имя или IP адрес тестируемого сервера WCS#2;
testStreamsCount — количество потоков для теста.
Тестирование
На тестирующем сервере WCS#1 с помощью примера "Media Devices" опубликуем поток под именем "test" с параметрами 1280x720, 30 fps, битрейт 2500 кбит/с.
Затем, в консоли тестирующего сервера, запускаем скрипт для тестирования со следующими параметрами:
./pull_push_test.sh test 172.16.40.3 172.16.40.2 200
где
test — имя опубликованного потока на WCS#1
172.16.40.3 — IP адрес тестирующего сервера WCS#1
172.16.40.2 — IP адрес тестируемого сервера WCS#2
200 — число потоков
Результат тестирования для 200 потоков на скриншоте ниже:
Тест был пройден успешно. Деградации стримов не было зафиксировано и контрольный поток воспроизводился с приемлемым качеством — без фризов, артефактов, снижения качества звука:
На нашем оборудовании тест завершился успешно. Хотелось бы напомнить, что на вашем оборудовании результаты тестирования могут меняться как в лучшую, так и в худшую сторону в зависимости от окружения, географического размещения серверов и пользователей - как подписчиков, так и стримеров.
Поэтому, рекомендуем, прежде чем принять окончательное решение по выбору серверов провести все возможные тесты, которые могут относиться к вашей задаче, и принимать решение опираясь на их результаты.
Хорошего стриминга!
Полезные файлы
Панель для Grafana:
Настройки WCS:
Скрипт для теста:
Наш демо-сервер
WCS на Amazon EC2 - Быстрое развертывание WCS на базе Amazon
WCS на DigitalOcean - Быстрое развертывание WCS на базе DigitalOcean
WCS в Docker - Запуск WCS как Docker контейнера
Управление параметрами публикации и воспроизведения Функции сервера по управлению различными параметрами публикации и воспроизведения видеопотоков
Документация по быстрому развертыванию и тестированию WCS сервера
Документация по мониторингу информации о нагрузке и ресурсах
Документация по организации мониторинга с помощью Prometheus