Нагрузочное тестирование создание, наполнения микшера и записи

[VyacheslavMik]

Добрый день, мы реализуем видеосессию до 3-х пользователей с браузера с возможностью записи. используем микширование потоков и через rest-api записываем. Ознакомился с https://docs.flashphoner.com/pages/viewpage.action?pageId=3049870 и https://docs.flashphoner.com/pages/viewpage.action?pageId=5668909, но это не позволяет нашу ситуацию смоделировать, подскажите как нам поступить, то есть писать свою утилиту, реализующую логику теста и через REST-API воспроизводить?
Хотелось бы узнать сколько комнат с 3-мя участниками сможет выдерживать с/без записи

 

[VyacheslavMik]

перечитал еще раз, создать комнаты с микшерами могу использовать /mixer/test/start.

я правильно, что если я хочу 100 комнат с уникальными стримами, то мне нужно в feedingSteams ложить 300 стримов, в mixerCount - 100,
streamsInMixer - 3, intervalInSeconds - сколько хочу писать каждый?
и если хочу проверить записанные файлы, то не получится это сделать, чтобы проверить этот кейс (к примеру запись мб есть, но там фризы. на 1-ой комнате все ок, при 50 начинаются микрофризы не везде, на 100-а во всех фризы и зависания)

 

[Max]

Добрый день.
Да, Вы правильно поняли логику работу нагрузочного теста микшеров. Добавим к этому, что по истечении intervalInSecons микшеры уничтожаются и создаются заново, тест продолжается до вызова /mixer/test/stop, либо до остановки сервера. Поэтому рекомендуется задать шаблон имени файла записи, обеспечивающий уникальность для каждой итерации теста, например

stream_record_policy_template={streamName}-{startTime}-{endTime}

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

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 7327 root      20   0     16.0t    47.3g  44.3g S  1645 60.3   295:49.75  java

Если параметр RES начинает резко расти, это означает, что процессор не успевает кодировать кадры выходных потоков микшеров, в этом случае в записях наверняка будут фризы, поскольку часть кадров входящих потоков будет сброшена. И, скорее всего, это будет означать, что количество комнат на данном сервере необходимо уменьшить.
Для публикации WebRTC потоков можно использовать как захват с другого сервера, так и захват VOD из файла по REST API. В этом случае в настройках сервера нужно указать, чтобы файл захватывался циклически (иначе файл может закончиться раньше желаемой длительности теста), а также увеличить таймаут, по истечении которого VOD-поток, не имеющий подписчиков, останавливается:

vod_live_loop=true
vod_stream_timeout=14400000

Отметим, что поддерживаются H264 + AAC файлы в контейнере mp4, при этом в файле не должно быть B-фреймов.

Хотелось бы узнать сколько комнат с 3-мя участниками сможет выдерживать с/без записи

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

 

[Max]

Добрый день.

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

 

[VyacheslavMik]

Добрый вечер, мы микшированный поток не проигрываем в реал-тайме на проде, недавно добавили вывод в реал-тайм для дебага (но это только на деве). ситуация с зависаниями что на деве, что на проде аналогичная. Но в архиве логи при проигрывании в реал-тайме (когда дебажили).
в общем картина:
1) публикуем потоки от каждого участника
2) проигрываем потоки других участников
2) запускаем микшер и записываем его (нигде он не используется кроме записи)
3) останавливаем запись и уничтожаем микшер

 

[Max]

Добрый день.
Фризы в выходном потоке микшера могут быть вызваны тем, что потоки от участников заходят в микшер по разному, с различным качеством. Например, если хотя бы в одном потоке будут задержки, микшер будет ожидать кадры из этого потока, чтобы не терять синхронизацию.
При достаточном объеме памяти на сервере (например, как у Вашего сервера, на котором вы собирали присланные логи) может помочь увеличение размера буфера для входящих потоков микшера при помощи настройки

mixer_video_buffer_length=150

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