Зависание при нагрузочном тестировании.

[Ilya K.]

Здравствуйте. Для тестов использую client2/examples/demo/streaming/console/console.html (Pull streams)

Публикую один поток, с другой машины эмулирую 500 подписчиков.
После >400 соединений рост прекращается, с этого момента подключаться, публиковать потоки нельзя до перезапуска.
Исходящая скорость при зависании приметно 400-500 мбит/с
Пробовал типы инстансов AWS c5.2xlarge c5.9xlarge - результат один.
Результат почти всегда одинаков при ice_tcp_transport=true и без неё.
Пробовал различные размеры MTU, txqueuelen, ice_tcp_receive_buffer_size, ice_tcp_send_buffer_size, heap_size
Подключить ZGC пока не получилось-перестаёт работать веб-интерфейс и публикация потоков, детально не изучал.
Динамические порты и рабочие порты Flashphoner не пересекаются.
Разные версии java (jdk1.8.0, jdk-15.0.1)
Без CDN.
Логи во вложении.
Linux 4.14.200-116.320.amzn1.x86_64 x86_64
Flashphoner 5.2.798

Требуется ли еще какая-нибудь информация?

 

[Max]

Добрый день!

Попробуйте все таки разобраться с запуском ZGC.

Рекомендованные JDK, с которыми протестирована работа сервера, это 12 или 14
(Инструкция по установке)

Для настройки ZGC выполните следующие действия:
1. Нужно закомментировать в файле wcs-core.properties следующие строки:

-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

2. Поправить настройки для логов

-Xlog:gc*:/usr/local/FlashphonerWebCallServer/logs/gc-core.log
-XX:ErrorFile=/usr/local/FlashphonerWebCallServer/logs/error%p.log

3. Выставить размер хипа не менее, чем 1/2 физической памяти сервера

### JVM OPTIONS ###
-Xmx16g
-Xms16g

4. Включаем ZGC

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

5. Настраиваем страницы памяти. Обязательно нужно рассчитать число страниц под размер выделенного хипа
(1,125*heap_size*1024)/2. Для -Xmx16g это число (1,125*16*1024)/2=9216

mkdir /hugepages
echo "echo 9216 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages" >>/etc/rc.local
echo "mount -t hugetlbfs -o uid=0 nodev /hugepages" >>/etc/rc.local
chmod +x /etc/rc.d/rc.local
systemctl enable rc-local.service
systemctl restart rc-local.service

Затем перезапустите WCS и попробуйте запустить тестирование.
Если проблема будет сохраняться, по возможности, пожалуйста, предоставьте SSH доступ к вашему серверу с помощью приватной формы.

 

[Ilya K.]

ZGC заработал с jdk-14, но проблема не ушла. Отправил данные в приватной форме.

 

[Max]

Подключится не удалось. Нужен приватный ключ вашего сервера.

Прислать ключ можно с помощью той же приватной формы

 

[Ilya K.]

Отправил повторно.

 

[Ilya K.]

Пока изменил адрес, нужен в работоспособном состоянии.

 

[Ilya K.]

Сервер сейчас не занят. Посмотрите, пожалуйста.

 

[Max]

Провели нагрузочное тестирование на вашем сервере.
При более 400 входящих соединений увеличивается нагрузка на сервер и стандартного ice_timeout=15 сек становится недостаточно.
Для решения проблемы укажите в файле flashphoner.properties настройку

ice_timeout=120

Дополнительно, в том же файле укажите настройку, которая увеличивает время на прохождение теста:

wcs_activity_timer_timeout=86400000

 

[Max]

По результатам тестирования видно, что максимальное количество подписчиков в Вашем случае зависит не от производительности сервера – ЦП и оперативной памяти, а упирается в пропускную способность сети.
Заявленные в датацентре 1гбит/с могут действовать только в пределах этого датацентра (для локальной сети), поэтому нужно замерить реальную ширину канала до места размещения подписчиков, и, уже исходя из этой информации, делать расчеты по количеству возможных подключений.
Например, если в результате замеров получился канал 500мбит/с, то максимально можно подключить 500 пользователей.
Из расчета 1стрим – 1мбит/с


Измерить пропускную способность канала можно при помощи утилиты iperf. Эта программа выпущена под все основные операционные системы: Windows, MacOS, Ubuntu/Debian, CentOS. iperf в режиме сервера может быть установлена вместе с WCS, что позволяет тестировать канал целиком, от паблишера до зрителя.

Запуск iperf в режиме сервера:

iperf3 -s -p 5201

здесь 5201 - порт, на который iperf ожидает соединений от тестирующих клиентов

Запуск iperf в режиме клиента для тестирования отправки данных от клиента к серверу по TCP:

iperf3 -c test.flashphoner.com -p 5201

Здесь:
test.flashphoner.com - WCS сервер
5201 - порт iperf в режиме сервера

для тестирования приема данных от сервера по TCP:

iperf3 -c test.flashphoner.com -p 5201 -R

Здесь:
test.flashphoner.com - WCS сервер
5201 - порт iperf в режиме сервера

Подробнее здесь

 

[Ilya K.]

Здравствуйте.
Большое спасибо за информацию, точно пригодится в тестировании. В данном случае была ошибка в iptables, не хватало портов. Поправил - зависание ушло. Большие нагрузки буду давать позже.

 

[Ilya K.]

Здравствуйте.

Вкратце хотим добиться:
Максимально возможное количество соединений на edge-сервере при раздаче потоков, лимит которых будет упираться в лимит CPU/и или памяти.
Edge имеют одно dns имя. Все edge за classic load balancer+auto scaling group. Соответственно потоки клиенты будут получать по dns имени балансировщика. Тесты проводились с одним edge.

Окружение:
клиент (тестирующий) - c5.4xlarge (CPU-16 RAM-32):
-Xmx16G
-Xms16G

edge - c5.4xlarge (CPU-16 RAM-32):
-Xmx16G
-Xms16G


origin - с5.2xlarge (CPU-8 RAM-16):
-Xmx8G
-Xms8G



Везде:
Версия:
5.2.838 (при обновлениях на более новые появляется проблема подключения по ws. По возможности хотел бы вернуться к этому позже. пока проверяю на той, что работает)
сборщик мусора - ZGC
ice_tcp_transport=true
net.ipv4.ip_local_port_range = 54001 65000
media_port_from=31008
media_port_to=47000
wcs_agent_port_from=49001
wcs_agent_port_to=53999
WCS_FD_LIMIT=100000
webrtc_cc2_twcc=false
Есть другие настройки, скорее всего ненужные.

iptables -S:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4431 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9100 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8888 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1935 -j ACCEPT
-A INPUT -p udp -m udp --dport 1935 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 554 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8081 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8084 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8082 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8445 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8444 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9091 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20000:53999 -j ACCEPT
-A INPUT -p udp -m udp --dport 20000:53999 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -j DROP
-A OUTPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -o lo -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
(некоторые порты от прежних настроек, будем убирать)


/etc/sysctl.conf сожержит:
fs.file-max = 100000
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_max_syn_backlog = 10240
net.ipv4.tcp_congestion_control=htcp
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 1024
net.core.netdev_max_backlog = 65536
net.core.optmem_max = 25165824
net.ipv4.tcp_mem = 65536 131072 262144
net.ipv4.udp_mem = 65536 131072 262144
net.core.rmem_default = 25165824
net.core.rmem_max = 25165824
net.ipv4.tcp_rmem = 20480 12582912 25165824
net.ipv4.udp_rmem_min = 16384
net.core.wmem_default = 25165824
net.core.wmem_max = 25165824
net.ipv4.tcp_wmem = 20480 12582912 25165824
net.ipv4.udp_wmem_min = 16384
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_reuse = 1
(по умолчанию не было, выставляли исходя из рекомендаций по настройке сети., ни на что не повлияло)

Проверка канала напрямую по внешнему ip (от тестирующего к edge):
iperf3 -c xxxxxx -p 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 579 MBytes 4.85 Gbits/sec 48 718 KBytes
[ 4] 1.00-2.00 sec 539 MBytes 4.52 Gbits/sec 103 870 KBytes
[ 4] 2.00-3.00 sec 566 MBytes 4.75 Gbits/sec 116 981 KBytes
[ 4] 3.00-4.00 sec 538 MBytes 4.51 Gbits/sec 153 397 KBytes
^C[ 4] 4.00-4.62 sec 349 MBytes 4.72 Gbits/sec 0 922 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-4.62 sec 2.51 GBytes 4.67 Gbits/sec 420 sender
[ 4] 0.00-4.62 sec 0.00 Bytes 0.00 bits/sec receiver


iperf3 -c xxxxxx -p 5201 -R
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 572 MBytes 4.79 Gbits/sec
[ 4] 1.00-2.00 sec 571 MBytes 4.79 Gbits/sec
[ 4] 2.00-3.00 sec 571 MBytes 4.79 Gbits/sec
[ 4] 3.00-4.00 sec 571 MBytes 4.79 Gbits/sec
^C[ 4] 4.00-4.61 sec 346 MBytes 4.78 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-4.61 sec 0.00 Bytes 0.00 bits/sec sender
[ 4] 0.00-4.61 sec 2.57 GBytes 4.79 Gbits/sec receiver


Edge находятся в AWS Classic load balancer+ Autoscaling group (настраивал согласно статье https://flashphoner.com/cdn-s-balan...rovaniem-na-baze-amazon-web-services/?lang=ru)
Тестирующий, origin, edge находятся в одной placement group. тип - cluster (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)

Проверка канала по dns имени балансировщика edge (от тестирующего к edge):
iperf3 -c xxxxxx -p 5201:
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 371 MBytes 3.11 Gbits/sec 95 235 KBytes
[ 4] 1.00-2.00 sec 471 MBytes 3.95 Gbits/sec 115 505 KBytes
[ 4] 2.00-3.00 sec 516 MBytes 4.33 Gbits/sec 229 472 KBytes
[ 4] 3.00-4.00 sec 365 MBytes 3.06 Gbits/sec 274 404 KBytes
[ 4] 4.00-5.00 sec 455 MBytes 3.82 Gbits/sec 106 359 KBytes
[ 4] 5.00-6.00 sec 514 MBytes 4.31 Gbits/sec 148 626 KBytes
[ 4] 6.00-7.00 sec 469 MBytes 3.93 Gbits/sec 182 293 KBytes
[ 4] 7.00-8.00 sec 436 MBytes 3.66 Gbits/sec 266 221 KBytes
[ 4] 8.00-9.00 sec 402 MBytes 3.38 Gbits/sec 144 444 KBytes
[ 4] 9.00-10.00 sec 440 MBytes 3.69 Gbits/sec 157 614 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 4.34 GBytes 3.72 Gbits/sec 1716 sender
[ 4] 0.00-10.00 sec 3.98 GBytes 3.42 Gbits/sec receiver

iperf3 -c xxxxxx -p 5201 -R:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 100 KBytes 822 Kbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
iperf3: error - control socket has closed unexpectedly

На тестирующей машине выставляется:
wcs_activity_timer_timeout=86400000
Тестировалось с помощью "pull streams" в количестве 1000 соединений. Указывался внешний IP непосредственно edge.
Исходный поток, опубликованный на origin имеет битрейт примерно от 1.5 до 2 мбит

При тестировании наблюдается следующее:
при достижении примерно 300 соединений (примерно 500 мбит/с) перестаёт расти скорость, так и остаётся - максимум 500 мбит/с. Количество соединений при этом увеличивается до 1000, как и было указано при запуске теста. При этом изображение начинает опаздывать, затем тормозить, если соединений больше, чем примерно 300.
Скорость замерялась утилитой nload.
Значительных нагрузок на CPU, память не наблюдается как на edge, так и на тестирующей машине.
Ставили много экспериментов, всё упирается в скорость раздачи в 500 мбит/с. Просьба помочь с настройками, дать рекомендации по настройке инфраструктуры, если допустили концептуальные ошибки.
Те же результаты наблюдались с типом машин edge, тестирующей- с5.2xlarge (CPU-8 RAM-16 -Xmx8G
-Xms8G).
Заранее спасибо.

 

[Max]

Добрый день!
По всей видимости у вас плохой канал не между серверами в датацентре, а между сервером и клиентом.
Рекомендую проверить с помощью Iperf ширину канала между серверами и рабочей станцией, на которой запускалось тестирование.

Дополнительно, нужно на тестирующем сервере xxx.xxx.xxx.202 тоже указать в настройках таймаут для тестирования:

wcs_activity_timer_timeout=86400000

С выставленной настройкой мы получили более 1000 потоков в тесте на ваших серверах без деградации стримов.

 

[Ilya K.]

Создал windows-машину в одной placement group вмеcте со всеми остальными. Результаты проверки канала от новой клиентской машины к остальным:

Edge:
Connecting to host xxx.65, port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 506 MBytes 4.24 Gbits/sec
[ 4] 1.00-2.00 sec 510 MBytes 4.29 Gbits/sec
[ 4] 2.00-3.00 sec 487 MBytes 4.09 Gbits/sec
[ 4] 3.00-4.00 sec 496 MBytes 4.16 Gbits/sec
[ 4] 4.00-5.00 sec 512 MBytes 4.30 Gbits/sec
[ 4] 5.00-6.00 sec 512 MBytes 4.29 Gbits/sec
[ 4] 6.00-7.00 sec 486 MBytes 4.06 Gbits/sec
[ 4] 7.00-8.00 sec 488 MBytes 4.11 Gbits/sec
[ 4] 8.00-9.00 sec 512 MBytes 4.29 Gbits/sec
[ 4] 9.00-10.00 sec 483 MBytes 4.05 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 4.88 GBytes 4.19 Gbits/sec sender
[ 4] 0.00-10.00 sec 4.87 GBytes 4.19 Gbits/sec receiver

iperf Done.


Тестирующий:
C:\iperf>iperf3 -c xxx.202 -p 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 467 MBytes 3.92 Gbits/sec
[ 4] 1.00-2.00 sec 509 MBytes 4.27 Gbits/sec
[ 4] 2.00-3.00 sec 502 MBytes 4.21 Gbits/sec
[ 4] 3.00-4.00 sec 476 MBytes 3.99 Gbits/sec
[ 4] 4.00-5.00 sec 516 MBytes 4.33 Gbits/sec
[ 4] 5.00-6.00 sec 483 MBytes 4.05 Gbits/sec
[ 4] 6.00-7.00 sec 504 MBytes 4.23 Gbits/sec
[ 4] 7.00-8.00 sec 483 MBytes 4.05 Gbits/sec
[ 4] 8.00-9.00 sec 500 MBytes 4.19 Gbits/sec
[ 4] 9.00-10.00 sec 493 MBytes 4.14 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 4.82 GBytes 4.14 Gbits/sec sender
[ 4] 0.00-10.00 sec 4.82 GBytes 4.14 Gbits/sec receiver

iperf Done.


Origin:
C:\iperf>iperf3 -c xxx.102 -p 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 529 MBytes 4.44 Gbits/sec
[ 4] 1.00-2.00 sec 522 MBytes 4.38 Gbits/sec
[ 4] 2.00-3.00 sec 537 MBytes 4.50 Gbits/sec
[ 4] 3.00-4.00 sec 520 MBytes 4.36 Gbits/sec
[ 4] 4.00-5.00 sec 519 MBytes 4.35 Gbits/sec
[ 4] 5.00-6.00 sec 508 MBytes 4.26 Gbits/sec
[ 4] 6.00-7.00 sec 499 MBytes 4.18 Gbits/sec
[ 4] 7.00-8.00 sec 526 MBytes 4.41 Gbits/sec
[ 4] 8.00-9.00 sec 535 MBytes 4.49 Gbits/sec
[ 4] 9.00-9.85 sec 448 MBytes 4.43 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-9.85 sec 5.02 GBytes 4.38 Gbits/sec sender
[ 4] 0.00-9.85 sec 0.00 Bytes 0.00 bits/sec

Запустил на ней тест (pull streams), 1000 соединений. (у исходного на origin битрейт 1.5-2.0 мбит/с )Результат такой же. Заметное опаздывание и торможение примерно от 300 соединений, максимальная скорость отдачи-450-500 мбит/с. Источник потока - веб-камера на физическом ПК. Битрейта вашего тестового потока хватает, чтобы добиться скорости 500 мбит/с и выше?

 

[Max]

Настроили на вашем Windows сервере тестовый стенд.
На стенде удалось получить около 2000 потоков без деградации контрольного стрима.

Рекомендуем отключить TCP транспорта на CDN серверах на время тестирования.

ice_tcp_transport=false

TCP помогает при потерях, но дает задержку, поэтому внутри CDN его имеет смысл использовать, только если задержка не важна, либо передаются толстые потоки, а канал не совсем хороший (Например, между континентами или в случае с VR потоками 4K).

Дополнительная информация по проведению тестирования с использованием мониторинга в статье https://flashphoner.com/kakoy-nuzhen-server-dlya-1000-webrtc-strimov/?lang=ru

 

[Ilya K.]

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

При тесте публикуем на xxx.102, воспроизводим на xxx.65.
На странице плеера, там, где wcs url ввожу xxx.65 - адрес edge. Т.е. всё также, как у вас в сообщении от вчерашнего дня в 12:31 PM на скринах.
После публикации потока на origin в тестовой консоли выбираю тестирующий xxx.202, pull streams, где choose node выбираю edge - xxx.65 (edge), количество - 1000.
Сначала публикуемый и воспроизводимый потоки синхронизированы. наблюдения сетевой нагрузкой говорят о том, что пороговая исходящая скорость устанавливается в районе 500 мбит/с на edge, такая же входящая на тестирующем. Это видно на вашем скрине с графиком графаны. Именно - global_bandwidth_in тестирующего инстанса xxx.202. Именно в этот момент начинается отставание. Почему он держится в районе 500 мбит/с? Разве не должно быть увеличения скорости по мере роста количества подписчиков? Т.е. на origin - 1.5 мбит/с, при 1 соединении edge также выдаёт исходящую скорость 1.5 мбит/с. При 100 соединениях 1.5*100=150 мбит/с. при 1000 1.5*1000=1500 мбит/с. Во вложении скрин nload с edge, когда появилось отставание, скрины тестов при синхронизированных потоках и где видно, что потоки уже не синхронизированы. Параллельно с первым на origin был запущен еще один поток, на него нагрузка не подавалась. При зависании первого, с которым производились тесты, второй был синхронизирован, проблемы не наблюдались. Изменение настройки ice_tcp_transport=false не помогло.
Тесты также проводил на той машине windows. Страница плеера с потоком от edge была открыта также на разных хостах-один результат. После остановки тестирующего сервера потоки почти моментально синхронизировались. В статье, к сожалению, не нашел нужной информации по сети. Указано только, что нагрузка на канал не превышает 5%. По вашим скринам видно, что потоки синхронизированы. Не могу понять, почему результаты так отличаются, даже при том условии, что запускали тест на одной машине. Что-то я делаю неверно.

 

[Max]

Еще раз протестировали с таймером.
Из-за особенностей виртуализации на Amazon, по умолчанию, все видеопотоки обрабатываются в одном процессорном треде. Получается, что только одно ядро обрабатывает всю нагрузку. (скриншот с xxx.65)

Рекомендуем применить настройку (в файле flashphoner.properties)

streaming_distributor_video_proxy_pool_enabled=true

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

Результаты теста с включенной настройкой:

Загрузка сети:

Распределение нагрузки на процессор:

Скриншот теста:

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

 

[Ilya K.]

Да, теперь ограничения сети в 500 мбит/с нет.
Большое спасибо, буду продолжать тесты.