Клиенты отваливаются через 10-30 секунд

Discussion in 'Web Call Server 5' started by alexanderY, Feb 27, 2017.

  1. Max

    Max Administrator Staff Member

    Документация по настройке нагрузочного теста здесь.
    Нагрузочный сервер запускает процессы Chrome, открывает стандартный плеер и играет поток.
  2. alexanderY

    alexanderY Member

    Спасибо! Пробовать будем уже завтра.

    Кстати, что такое снапшоты в данном контексте?
  3. Max

    Max Administrator Staff Member

    Снапшоты - это снимки видеопотока в формате PNG без его воспроизведения.
    Например, если мы выводим на сайт видео с 10 камер одновременно, то будет большой битрейт. Можно периодически раз в 10 секунд делать снимки потока и показывать что происходит в виде картинок. Это и есть снапшоты. Пример здесь.
  4. alexanderY

    alexanderY Member

    Спасибо.

    Попробовал настроить нагрузочное тестирование. Пришлось сделать несколько небольших изменений:
    1. В файл player.html добавил jquery, иначе была ошибка в utils.js
    2. В файле player.js был захардкожен IP-адрес Flashphoner-сервера, поменял на строку var url = getUrlParam("url") || "ws://192.168.1.40/flashphoner-rtc";
    Дальше по шагам, что делал:
    1. Установил всё по инструкции, запустил Xorg (как проверить, что он работает, кстати?)
    2. Открыл на своем декстопе стандартное демо "Streamer", указал для подключения "wss://192.168.1.70:8443/stream1" — опубликовал стрим
    3. Проверил другим браузером http://192.168.1.80/tests/player/pl...stream1&url=ws://192.168.1.40/flashphoner-rtc - открывается, стрим воспроизводится
    4. На сервере с xload проверил wget'ом, что страница http://192.168.1.80/tests/player/pl...stream1&url=ws://192.168.1.40/flashphoner-rtc доступна
    5. Запускаю /vagrant/xload/loadtest.sh -url 'http://192.168.1.80/tests/player/pl...stream1&url=ws://192.168.1.40/flashphoner-rtc' -ttl 30 -maxsubscribers 50 -stressrate 1000
    В результате, на сервере с Flashphoner нагрузка никак не увеличилась (смотрел по top). В логе stress.log вроде бы никаких ошибок http://pastebin.com/mVeH4isU
    Не похоже, что сервер с Flashphoner был нагружен хоть немного.
  5. alexanderY

    alexanderY Member

    По ссылке указано "mv -R jdk-8u25 /usr/java/jdk-8u25", но у команды mv нет ключа R. Что имеется в виду?
    И второй вопрос, нельзя ли установить Oracle JDK из репозитория ppa:webupd8team/java, как описано здесь?
  6. Max

    Max Administrator Staff Member

    Ошибка в документации. Нужно просто
    Code:
    mv jdk-8u25 /usr/java
    Смысл ручной установки JDK в том, что мы просто распаковываем ее и копируем в /usr/java (можно в любой другой каталог, например /opt/java).
    Далее ставим ссылку
    Code:
    ln -sf /usr/java/default/bin/java /usr/bin/java
    Можно. Главное понимать куда она установлена в файловой системе, чтобы позже можно было легко использовать keytool или jstack если будет нужно. Они находятся в %JDK_HOME%/bin
  7. Max

    Max Administrator Staff Member

    Скрипт loadtest.sh берет на вход url плеера, далее должен запуститься Chrome и открыть эту страницу.
    Т.е. правильным был бы такой запуск
    Code:
    ./loadtest.sh -url http://yourpage.html -ttl 30 -maxsubscribers 50 -stressrate 1000
    Просто убедитесь что скрипт работает и загружает произвольную страницу, например с вашего сайта.
    Например в данной конфигурации Chrome должен открывать страицу со скоростью 1 страница в секунду, максимум 50 страниц и держать их открытыми 30 секунд.
    Проверить есть ли активность, можно в процессах и в сети.
    Например:
    Code:
    ps aux | grep -i chrome
    Или посмотреть траффик
    Code:
    ps aux | grep -i chrome
    там должна быть видна загрузка страниц в wireshark
  8. Max

    Max Administrator Staff Member

    Если скрипт заработал, то можете просто подставить ему параметром свою страницу myplayer.html, которая начинает автоматически играть стрим.
    Скрипт сам не выполняет никакой логики стриминга, просто открывает html-страницы в Chrome процессах.
  9. alexanderY

    alexanderY Member

    Сегодня заработало. Возможно, вчера было дело именно в ошибках скрипта (не хватало jquery и прочее, я писал выше). Либо я не проверил после исправления ошибок, либо страницы закешировались. Потому что я проверял - процессы chrome создавались корректно, но сервер с Flashphoner никакой нагрузки в это время не испытывал. Сегодня сразу стало видно. Запускаем скрипт - начинает расти нагрузка, т.е. стрим реально воспроизводится.

    Значит, если на странице воспроизводится три стрима, каждый экземпляр Хрома будет эти три стрима "смотреть", верно? При условии автоматического воспроизведения.
  10. Max

    Max Administrator Staff Member

    Да, верно. xload Chrome откроет страницу так, как если бы она была открыта с нормального компьютера. Далее работает JavaScript, который может реализовать любой нагрузочный сценарий. В самом простом случае - играть один поток автоматически.
  11. alexanderY

    alexanderY Member

    Немного потестировал и есть немного информации, для всех интересующихся:
    1. При ограничении максимального битрейта webrtc_cc_max_bitrate=400000, при одном стриме и одном зрителе стабильно занято 500-530 kbps, по данным atop. При отключении стрима 0 kbps, т.е. никаких других источников трафика нет. Более подробно не смотрел, так что не уверен — либо здесь идёт статичный оверхед в 100 kbps, либо в 25% от исходного.
    2. В большинстве тестов расчетный трафик совпадает с реальным (50 зрителей, 1 стрим, по 500 kbps = 25 mbps), но один раз было, что трафик вырос в пике до 78 mbps. Но сервер не упал, всё было в порядке. Почему так вырос трафик, мне непонятно.
    3. Не все процессы Хрома корректно завершаются. Приходится делать 'pkill -f chrome' вручную.
  12. alexanderY

    alexanderY Member

    Вышесказанное - относится к виртуалкам на девелоперской машине. Сейчас тестируем на продакшене. Вроде бы всё как надо. Один момент, скорее всего ничего особенного, но на всякий случай сообщаю. Когда процессы Хрома начинают отмирать потихоньку, на сервере видно уменьшение трафика на основном сетевом интерфейсе, но при этом периодически на lo бывают всплески до 10-20 mbps (при том, что на основном уже меньше 10 mbps). Это при 30 subscribers.
  13. alexanderY

    alexanderY Member

    Хмм. Всё хорошо, пока воспроизводится 1 стрим. Стабильные 15 mbps при 30 зрителях. Подключаю ещё один стрим.
    Ожидание: рост трафика до 30 mbps.
    Реальность: постепенный рост трафика до 150 mbps в течение минуты; тормоза видео; дальше я отключаю второй стрим, чтобы не попасть под санкции хостера.
    После отключения второго стрима всё возвращается к нормальным 15 mbps.

    Апдейт: в девелоперской среде такого не повторяется. Только в продакшене.
    Last edited: Mar 10, 2017
  14. Max

    Max Administrator Staff Member

    Протестируем этот кейс на своем хостинге. Проверим, что получается.
    Сейчас мы занимаемся битрейтами и сделали в последних билдах 2122 следующее.
    События о проблемах в получении стрима
    1. Зритель автоматически отдаёт серверу информацию о том, какой битрейт он в состоянии получить.
    2. Сервер постоянно измеряет битрейт Стримера
    3. Если битрейт, который Зритель может получить, ниже текущего битрейта Стримера на 10% и более, то на клиента высылается событие StreamStatusEvent (последниие версии Web SDK).
    Выглядит это так:
    local_cc.jpg
    Т.е. будет высылаться событие, которое говорит о том, что у зрителя недостаточный канал для принятия потока, который генерирует Стример.
    Корректировка стримера зрителями
    Допустим два и более Зрителей смотрят одного Стримера.
    Зритель 1 - может забирать поток 200 kbps
    Зритель 2 - может забирать поток 400 kbps
    Стример отдает поток 500 kbps
    Сервер настроен по-умолчанию:
    Code:
    webrtc_cc2_min_remb_bitrate_bps =100000
    В этом случае WCS потребует от Стримера уменьшить битрейт до 200 kbps, равняясь на самого слабого зрителя. Но не будет понижать битрейт Стримера ниже порога в настройке webrtc_cc2_min_remb_bitrate_bps remb_based_proxy_cc.jpg Таким образом, если зрители начнут испытывать проблемы со стримом, WCS потребует от Стримера ужать полосу, но не ниже порога. Надеемся, что это может оперативно разгрузить сеть и предотвратить сбои.
    Настройки и тестирование
    Мы тестируем эти изменения с последними сборками и кодеком H.264 в приоритете.
    Code:
    codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
    webrtc_cc2_min_remb_bitrate_bps =100000
  15. alexanderY

    alexanderY Member

    Любопытно. А как-нибудь учитывается, если зритель смотрит нескольких стримеров? На просмотр одного, например, ему хватает канала, но на двоих суммарно уже нет.

    Правильно ли я понимаю, что один зритель с плохим каналом может заставить других "страдать", если выставить слишком низкий порог в
    webrtc_cc2_min_remb_bitrate_bps? Думаю, рекомендуемый порог 256-300 kbps? Я просто в одно время тестировал стрим, понижал битрейт с 1.4 mbps до 256 kbps и на глаз разницы не заметил (камера 640x480).

    И еще вопрос, насчет новых сборок. Вы рекомендуете обновляться почаще или "работает - не трогай"?
  16. Max

    Max Administrator Staff Member

    К сожалению, cc2 (congestion control 2) пока не прошел тестирование.
    Битрейт очень сильно снижается до нижнего порога 100 kbps. Поэтому в последней сборке 2123 пришлось временно откатить эту настройку. Это предотвращает перегрузку, но портит качество. На следующей неделе планируем доделать это для production-состояния.
  17. Max

    Max Administrator Staff Member

    Мы сейчас плотно работаем над congestion control (управление перегрузками).
    И по факту у нас есть два алгоритма для Стримеров:
    СС 1
    Code:
    webrtc_cc2=false
    default в 2123
    СС 2
    Code:
    webrtc_cc2=true
    CC1 работает нормально с кодеком VP8 и восстанавливает битрейт.
    CC2 роняет битрейт при атаке на CPU или сеть (на клиенте) и не восстанавливается.
    Для зрителей у нас есть уведомления, плюс возможность влиять на стримеров до определенного порога, которая есть в CC2.

    Это уже решает Chrome. Он анализирует полученные стримы и сигнализирует WCS о том, какой битрейт для него был бы оптимален в этот момент для каждого из стримов.

    Да. Поэтому порог должен быть не слишком низким.
    Если зритель просит слишком низкий битрейт, есть смысл предложить ему переключиться на поток с специально пониженным разрешением и битрейтом.
    Для этого можно сделать так, чтобы Стример публиковал резервный стрим с заведомо низким битрейтом. Например 176x144, 10 fps.

    Разницы не заметно, если нет движения в кадре.
    На движениях при низком битрейте идут макроблоки (квадратики) и размывают видео. А так да, с низким битрейтом можно работать.

    Почаще - точно не стОит. Стоит обновляться, когда польза от обновления заведомо известна, дает конкретный ожидаемый результат (например, важный конкретно в вашем кейсе фикс) и перекрывает возможные риски регрессий.
  18. alexanderY

    alexanderY Member

    Добрый вечер. Извините за настырность, но удалось ли повторить поведение, описанное в №33? Я немного в растерянности, т.к. в девелоперской среде я не могу это повторить. Зато в продакшене сколько угодно.
  19. Max

    Max Administrator Staff Member

    Мы пока проверили только в локальной сети. Локально не воспроизводится. Сейчас развернули на digitalocean. Результаты будут, скорее всего, завтра.
    Короткие всплески битрейта локально удалось воспроизвести при искуственном ограничении пропускной полосы в самой Linux - системе. Т.е. если насильно зажать полосу до 1 Mbps, а потом быстро отпустить наблюдаются всплески. Если полосу не зажимать - все идёт нормально.

    Т.е. пока надеемся что-то найти в деплое на digitalocean.
    На текущий момент предположения следующие
    1) Зажимается полоса хостером, потом отпускает и идут такие скачки
    2) Падает производительность сервера. В результате он тормозит на какое-то время, а потом выдает много данных.
    3) Ошибка измерения
    Например, если вы вмнесто 30 плееров, подключаете 30 пользователей к одной комнате, и каждый из подключенных пользователей пытается тянуть на себя потоки всех остальных в этой комнате. Например, если поток каждого пользователя 0.5 Mbps и каждый из 30 пользователей тянет 29 потоков, то это почти 450 Mbps.
    В статистике сервера
    http://host:8081/?action=stat&params=streams_viewers
    Можно наблюдать сколько зрителей у каждого из публикуемых потоков.
  20. Max

    Max Administrator Staff Member

    Проблему воспроизвели.
    Вспышка трафика происходит, когда зажат канал в одну сторону.
    Например ваш канал 20 Mbps, а вы тянете на него 30 Mbps - Download.
    В этом случае часть пакетов сбрасываются на сетевом уровне, т.к. не входят в полосу.
    Chrome браузеры при этом начинают спамить WCS-сервер NACK-пакетами, запрашивая потерянное видео.
    WCS досылает потерянные пакеты, но они снова теряются, т.к. не входят в полосу, и т.д. В результате происходит разгон битрейта до таких значений.

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

Share This Page