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

Discussion in 'Web Call Server 5' started by VyacheslavMik, Jan 20, 2020.

  1. VyacheslavMik

    VyacheslavMik New Member

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

    VyacheslavMik New Member

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

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

    Max Administrator Staff Member

    Добрый день.
    Да, Вы правильно поняли логику работу нагрузочного теста микшеров. Добавим к этому, что по истечении intervalInSecons микшеры уничтожаются и создаются заново, тест продолжается до вызова /mixer/test/stop, либо до остановки сервера. Поэтому рекомендуется задать шаблон имени файла записи, обеспечивающий уникальность для каждой итерации теста, например
    Code:
    stream_record_policy_template={streamName}-{startTime}-{endTime}
    
    Проверять записи лучше по окончании теста. Косвенно, Вы можете определить, каким будет качество, по загрузке процессора, контролируемой при помощи команды top, например:
    Code:
      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-поток, не имеющий подписчиков, останавливается:
    Code:
    vod_live_loop=true
    vod_stream_timeout=14400000
    
    Отметим, что поддерживаются H264 + AAC файлы в контейнере mp4, при этом в файле не должно быть B-фреймов.
    При использовании микшера, основную нагрузку дает именно микширование, поскольку при этом декодируется каждый входящий поток микшера и затем кодируется исходящий. Запись в данном случае повлияет только на общую производительность оборудования, т.к. будет интенсивно использоваться диск.
    VyacheslavMik likes this.
  4. Max

    Max Administrator Staff Member

    Добрый день.

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

    VyacheslavMik New Member

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

    Max Administrator Staff Member

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

Share This Page