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

[Max]

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

 

[alexanderY]

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

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

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

 

[Max]

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

 

[alexanderY]

Спасибо.

Попробовал настроить нагрузочное тестирование. Пришлось сделать несколько небольших изменений:

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 был нагружен хоть немного.

 

[alexanderY]

1. Устновить JDK 1.8 Oracle HotSpot, как описано здесь

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

 

[Max]

По ссылке указано "mv -R jdk-8u25 /usr/java/jdk-8u25", но у команды mv нет ключа R. Что имеется в виду?

Ошибка в документации. Нужно просто

mv jdk-8u25 /usr/java

Смысл ручной установки JDK в том, что мы просто распаковываем ее и копируем в /usr/java (можно в любой другой каталог, например /opt/java).
Далее ставим ссылку

ln -sf /usr/java/default/bin/java /usr/bin/java

И второй вопрос, нельзя ли установить Oracle JDK из репозитория ppa:webupd8team/java

Можно. Главное понимать куда она установлена в файловой системе, чтобы позже можно было легко использовать keytool или jstack если будет нужно. Они находятся в %JDK_HOME%/bin

 

[Max]

В результате, на сервере с Flashphoner нагрузка никак не увеличилась

Скрипт loadtest.sh берет на вход url плеера, далее должен запуститься Chrome и открыть эту страницу.
Т.е. правильным был бы такой запуск

./loadtest.sh -url http://yourpage.html -ttl 30 -maxsubscribers 50 -stressrate 1000

Просто убедитесь что скрипт работает и загружает произвольную страницу, например с вашего сайта.
Например в данной конфигурации Chrome должен открывать страицу со скоростью 1 страница в секунду, максимум 50 страниц и держать их открытыми 30 секунд.
Проверить есть ли активность, можно в процессах и в сети.
Например:

ps aux | grep -i chrome

Или посмотреть траффик

ps aux | grep -i chrome

там должна быть видна загрузка страниц в wireshark

 

[Max]

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

 

[alexanderY]

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

Скрипт сам не выполняет никакой логики стриминга, просто открывает html-страницы в Chrome процессах.

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

 

[Max]

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

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

 

[alexanderY]

Немного потестировал и есть немного информации, для всех интересующихся:

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' вручную.

 

[alexanderY]

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

 

[alexanderY]

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

Апдейт: в девелоперской среде такого не повторяется. Только в продакшене.

 

[Max]

Протестируем этот кейс на своем хостинге. Проверим, что получается.
Сейчас мы занимаемся битрейтами и сделали в последних билдах 2122 следующее.
События о проблемах в получении стрима
1. Зритель автоматически отдаёт серверу информацию о том, какой битрейт он в состоянии получить.
2. Сервер постоянно измеряет битрейт Стримера
3. Если битрейт, который Зритель может получить, ниже текущего битрейта Стримера на 10% и более, то на клиента высылается событие StreamStatusEvent (последниие версии Web SDK).
Выглядит это так:

Т.е. будет высылаться событие, которое говорит о том, что у зрителя недостаточный канал для принятия потока, который генерирует Стример.
Корректировка стримера зрителями
Допустим два и более Зрителей смотрят одного Стримера.
Зритель 1 - может забирать поток 200 kbps
Зритель 2 - может забирать поток 400 kbps
Стример отдает поток 500 kbps
Сервер настроен по-умолчанию:

webrtc_cc2_min_remb_bitrate_bps =100000

В этом случае WCS потребует от Стримера уменьшить битрейт до 200 kbps, равняясь на самого слабого зрителя. Но не будет понижать битрейт Стримера ниже порога в настройке webrtc_cc2_min_remb_bitrate_bps

Таким образом, если зрители начнут испытывать проблемы со стримом, WCS потребует от Стримера ужать полосу, но не ниже порога. Надеемся, что это может оперативно разгрузить сеть и предотвратить сбои.
Настройки и тестирование
Мы тестируем эти изменения с последними сборками и кодеком H.264 в приоритете.

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
webrtc_cc2_min_remb_bitrate_bps =100000

 

[alexanderY]

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

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

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

 

[Max]

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

 

[Max]

Мы сейчас плотно работаем над congestion control (управление перегрузками).
И по факту у нас есть два алгоритма для Стримеров:
СС 1

webrtc_cc2=false

default в 2123
СС 2

webrtc_cc2=true

CC1 работает нормально с кодеком VP8 и восстанавливает битрейт.
CC2 роняет битрейт при атаке на CPU или сеть (на клиенте) и не восстанавливается.
Для зрителей у нас есть уведомления, плюс возможность влиять на стримеров до определенного порога, которая есть в CC2.

А как-нибудь учитывается, если зритель смотрит нескольких стримеров?

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

Правильно ли я понимаю, что один зритель с плохим каналом может заставить других "страдать", если выставить слишком низкий порог в
webrtc_cc2_min_remb_bitrate_bps?

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

Я просто в одно время тестировал стрим, понижал битрейт с 1.4 mbps до 256 kbps и на глаз разницы не заметил (камера 640x480).

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

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

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

 

[alexanderY]

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

 

[Max]

Мы пока проверили только в локальной сети. Локально не воспроизводится. Сейчас развернули на 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
Можно наблюдать сколько зрителей у каждого из публикуемых потоков.

 

[Max]

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

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