Ограничение на количество участников в MCU?

[gekz]

Добрый день, проводили тест, суть теста в следующем :
максимальное количество участвующих в одном микшере (планировали 30 человек), но уже при 15+ участниках начались обрывы связи, а при 21-22 так вообще кого-то слышно, а кого-то нет, картинки подвисают и тд

Все потоки по 320х240 (700кб/с битрейт)

У нас физический сервер (112 ядер,256гига памяти), 10гигабит сетевая и канал) соответственно дело похоже не в железе и вот статистика при 20 человеках в микшере по ядрам:

По сети тоже ~ 32 Мбит/с и прыгало до 50 Мбит/с

Вопрос:

1. есть ли какое ограничение в алгоритмах сервера/микшера по максимальному числу реальных участников при котором будет полноценная конференция в режиме реального времени ? Так как по https://docs.flashphoner.com/pages/viewpage.action?pageId=9241750 тестировали и большее количество и сервера хватает.
2. по rest api по запросу /mixer/find_all показывает, что в микшере 21 поток, но при отображение сетка 4*5. Правильно ли я понимаю, что отображает на экране максимум 20 человек при настройке (CenterNoPaddingGridLayout). Возможно из-за этого кого не отображает и звук соотв. не слышно ?
3. и самый главный: как найти узкое место в схеме и где, так сказать, копать. Может настройки какие есть? Если нужно могу скинуть настройки используемые у нас (wcs-core, flashphoner или какие нужны). Java 14, сборщик мусора: Concurrent Mark Sweep (CMS) Collector

Спасибо.

 

[Max]

Добрый день

есть ли какое ограничение в алгоритмах сервера/микшера по максимальному числу реальных участников при котором будет полноценная конференция в режиме реального времени ? Так как по https://docs.flashphoner.com/pages/viewpage.action?pageId=9241750 тестировали и большее количество и сервера хватает.

Нет, таких ограничений нет

по rest api по запросу /mixer/find_all показывает, что в микшере 21 поток, но при отображение сетка 4*5. Правильно ли я понимаю, что отображает на экране максимум 20 человек при настройке (CenterNoPaddingGridLayout). Возможно из-за этого кого не отображает и звук соотв. не слышно ?

Любой layout отвечает только за размещение картинок в выходном потоке микшера, поток в микшере все равно при этом должен быть. Возможно, это баг. Мы создали внутренний тикет WCS-2902 для того, чтобы провести нагрузочные тесты, если получим воспроизведение проблемы с CenterNoPaddingGridLayout, выделим для нее отдельный тикет и сообщим здесь.

и самый главный: как найти узкое место в схеме и где, так сказать, копать. Может настройки какие есть? Если нужно могу скинуть настройки используемые у нас (wcs-core, flashphoner или какие нужны). Java 14, сборщик мусора: Concurrent Mark Sweep (CMS) Collector

Первое, что нужно сделать - это переключиться на ZGC, он дает меньшие (и, главное, фиксированные) паузы в работе Java машины при сборке мусора, что положительно влияет на производительность.
Также рекомендуем на железных серверах, выполняющих задачи транскодинга (а микширование - тоже транскодинг):
- отключать Hyperthreading;
- включать TurboBoost (при его наличии);
- следить, чтобы CPU governor не находился в режиме powersave, рекомендуемый режим balanced, на некоторых серверах throughput-perfomance или аналогичный режим, в зависимости от того, что показывает tuned-adm
Все это помогает планировщику более равномерно размазывать потоки по ядрам CPU.
В Вашем случае узкое место может быть в декодировании большого числа потоков. Поскольку поддерживается многопоточное декодирование, можно попробовать понизить границу разрешения входящего стрима, при котором включается декодирование в два потока. По умолчанию в два потока декодируются стримы 720p, в данном случае можно попробовать включить эту возможность для стримов 320x240

video_decoder_max_threads = 2
video_decoder_second_thread_threshold = 76800

Все потоки по 320х240 (700кб/с битрейт)

Уточните, пожалуйста, все потоки подаются с одного ПК или с нескольких? Хватает ли канала от места публикации до сервера, если, например, публикация идет с одного ПК или с нескольких ПК в одной локальной сети?
Например, при одновременной публикации 15 потоков битрейтом 700 кбит/с займут полосу 10,5 Мбит/с в канале от места публикации до сервера, соответственно, канал должен быть не менее 15 Мбит/с, чтобы обеспечить запас
Имеется в виду не пропускная способность интерфейса сервера, а канал целиком от точки до точки, включая последнюю милю.

 

[Max]

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

 

[gekz]

Добрый вечер,
прошу прощение за задержку с ответом, неделя была трудная.

Любой layout отвечает только за размещение картинок в выходном потоке микшера

Имелось ввиду если, предположим, все работает корректно, то правильно ли я понимаю что на экране будет 20 картинок? И что будет с другими, которые есть в микшере, но не попали в первую 20тку? Можно ли "листать" и тд

Первое, что нужно сделать - это переключиться на ZGC

Вот тут как раз пробовали, но у нас при подключении получается некий баг (или особенность работы ZGC), что раз в какое-то время на доли секунды абсолютно все картинки участников размываются и потом обратно восстанавливаются, причем происходит это довольно часто и очень бросается в глаза. В связи с этим переключились на (CMS) Collector, по памяти и ядрам какой-то разницы не заметили, но хоть картинка не плывет. Не знаю с чем связано, может из-за того что у нас стоит Java 14.

Уточните, пожалуйста, все потоки подаются с одного ПК или с нескольких?

В условиях карантина это все были уникальные пользователи с разных устройств/мест/каналов


Все остальные настройки сделали по Вашему совету, при следующем большом тесте проверим, что получилось.

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

# Config flashphoner.properties
# To get more settings:
# ssh -p 2001 admin@localhost
# default password: admin
# show node-settings
# show node-settings | grep port

#server ip
ip                     =*.*.*.*
ip_local               =*.*.*.*

#webrtc ports range
media_port_from        =31001
media_port_to          =52000

#codecs
codecs                   =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,flv,mpv
codecs_exclude_sip       =mpeg4-generic,flv,mpv
codecs_exclude_streaming =flv,telephone-event
codecs_exclude_sip_rtmp  =opus,g729,g722,mpeg4-generic,vp8,mpv

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


enable_extended_logging=false
streaming_video_decoder_fast_start=true
webrtc_cc2_twcc=false
webrtc_cc_min_bitrate=300000
mixer_audio_silence_threshold=-25.0
mixer_mcu_audio=true
mixer_mcu_video=true
mixer_text_autoscale=true
mixer_minimal_font_size=6
mixer_text_cut_top=0
mixer_text_padding_bottom=1
mixer_text_padding_left=1
mixer_text_padding_right=1
mixer_text_padding_top=1
mixer_text_colour=0x000000
mixer_text_background_colour=0xD3D3D3
mixer_idle_timeout=10000
mixer_display_stream_name=true
mixer_voice_activity=true
mixer_realtime=true
mixer_layout_class=com.flashphoner.media.mixer.video.presentation.CenterNoPaddingGridLayout
mixer_voice_activity_frame_thickness=4
mixer_voice_activity_frame_position_inner=true
encoder_priority=OPENH264
mixer_video_height=720
mixer_video_width=1280
mixer_lossless_video_processor_enabled=false

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

 

[Max]

Имелось ввиду если, предположим, все работает корректно, то правильно ли я понимаю что на экране будет 20 картинок? И что будет с другими, которые есть в микшере, но не попали в первую 20тку? Можно ли "листать" и тд

Во всех вариантах расположения, на экране будут картинки всех потоков в микшере. Соответственно, листать их не нужно. Мы проверим в наших тестах, воспроизводится ли проблема, но сначала решим задачу оптимизации микширования с учетом Вашего кейса.
Поскольку вы планируете много потоков в одном микшере, следует увеличить размер картинки самого микшера, т.к. изображения потоков масштабируются под этот размер. 1280x720 недостаточно для 30 планируемых картинок, они будут мелкими,поэтому рекомендуем увеличить разрешение микшера до 1080p.

Вот тут как раз пробовали, но у нас при подключении получается некий баг (или особенность работы ZGC), что раз в какое-то время на доли секунды абсолютно все картинки участников размываются и потом обратно восстанавливаются, причем происходит это довольно часто и очень бросается в глаза.

Любой сборщик мусора полностью останавливает Java машину. ZGC декларирует длительность паузы в 10 миллисекунд. Необходимо смотреть логи gc-core-*.log, либо подключаться к серверу при помощи JMC и смотреть графики расхода памяти в куче, графики загрузки процессора, чтобы определить, отчего возникают такие паузы. Как вариант, нужно выделить больше памяти под Java heap, тогда сборщик мусора будет запускаться реже.

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

это повлияет только на тех клиентов, которые поддерживают только VP8 (например, последние сборки Firefox для Android и большинство Chromium-браузеров, которые по умолчанию не поддерживают H264, если этот кодек не установлен в системе), они не смогут в таком случае стримить.

 

[gekz]

Возможно, это баг. Мы создали внутренний тикет WCS-2902 для того, чтобы провести нагрузочные тесты, если получим воспроизведение проблемы с CenterNoPaddingGridLayout, выделим для нее отдельный тикет и сообщим здесь.

Добрый день, сегодня методом проб таки убедились, что с данной опцией в микшере есть проблемы. При одних и тех же настройках и всем прочим, с включенной опцией "CenterNoPaddingGridLayout" начинаются подтормаживания и зависание как картинок так и звука и не возможно общаться. Отключив только эту опцию и оставив по умолчанию формат сетки (с отступами) все становится нормально, что очень жаль, так как опция полезная когда много людей и максимально эффективно используется все пространство выходного потока микшера.
Версия flashphoner'a: 5.2.777

 

[Max]

Наши тесты выявили несколько узких мест в микшировании, в данный момент проводится предварительное тестирование изменений по тикету WCS-2902. После применения оптимизаций, проблемы с использованием CenterNoPaddinGridLayout в наших тестах не воспроизводятся.
Основные узкие места связаны с выводом подписей и использованием MCU (что приводит к дополнительному кодированию аудиопотоков, при 30 участниках будет кодироваться 61 аудиопоток).
Мы сообщим, когда будет выпущена сборка с изменениями и дополнительными настройками.

 

[Max]

Добрый день.
В сборке 5.2.793 была добавлена возможность многопоточного микширования для оптимизации работы микшера в условиях большого количества участников. С Вашими настройками в наших тестах микшер на 30 участников играл плавно при следующих настройках оптимизации:

mixer_type=MULTI_THREADED_NATIVE
mixer_mcu_multithreaded_mix=true
mixer_mcu_multithreaded_delivery=true
mixer_audio_threads=10
mixer_video_threads=4

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

mixer_text_bulk_write=false
mixer_text_bulk_write_with_buffer=false

Это несколько снизит производительность, но уберет мерцание.