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

[Max]

Добрый день.
Проблема с вспышками трафика должна быть решена в последней сборке.
Если обнаруживается, что более 15% битрейта уходит на ретрансмиты, то такие ретрансмиты будут остановлены для каждой сессии в отдельности.

 

[alexanderY]

Например, если вы вмнесто 30 плееров, подключаете 30 пользователей к одной комнате, и каждый из подключенных пользователей пытается тянуть на себя потоки всех остальных в этой комнате. Например, если поток каждого пользователя 0.5 Mbps и каждый из 30 пользователей тянет 29 потоков, то это почти 450 Mbps.

Точно не наш случай. 30 пользователей действительно подключаются к одной комнате, но в комнате всего два пользователя стримят. Остальные - пассивные зрители. connect, join и затем play любых remote streams.

В статистике сервера
http://host:8081/?action=stat&params=streams_viewers

Спасибо за эту наводку, с первого раза не завелось почему-то, но подробно не копал. Скорее всего порт закрыт на виртуалке, посмотрю подробнее завтра-послезавтра.

Вспышка трафика происходит, когда зажат канал в одну сторону.
Например ваш канал 20 Mbps, а вы тянете на него 30 Mbps - Download.

Возможно конечно. Но вообще тариф у меня 50 мбит/сек, speedtest показывает стабильные 50-55 мбит как на upload, так и на download. С торрентов по факту скорость скачивания ещё выше. Разве что действительно при одновременном запросе 30 стримов происходит некий скачок. Тогда, я думаю, стоит попробовать добавить случайную задержку в 1-5 секунд перед тем, как воспроизводить новый стрим.

Последнюю сборку также протестируем на днях. Правильно ли я понял, что проблема 15% ретрансмитов, если обнаружится, не повлияет на сервер и других юзеров? Только одна конкретная сессия будет обрываться?

 

[Max]

Последнюю сборку также протестируем на днях. Правильно ли я понял, что проблема 15% ретрансмитов, если обнаружится, не повлияет на сервер и других юзеров? Только одна конкретная сессия будет обрываться?

Мы пока тестировали только общее поведение сервера и убедились, что трафик не растёт.
У сессии, которая исчерпала лимит ретрансмитов, скорее всего будет фриз. Но отдельные сессии в таких условиях пока не проверяли.

Правильно ли я понял, что проблема 15% ретрансмитов, если обнаружится, не повлияет на сервер и других юзеров?

Да, проблемы будут только у тех, на которых высокий рейт потерь.

 

[alexanderY]

Обновились. Протестировали один раз, пишу по горячим следам, так сказать.
С количеством трафика проблем больше нет. 2 стрима x 30 зрителей = 30 мбит/сек. Как и должно быть.

Ставил xload на 10 минут. По окончанию 10 минут зрители стали уходить, но вместе с этим оборвались и стримы, у обоих. В консоли браузера ошибка "Error: Invalid session state". Обновление страницы не помогает - более подключиться не получается. Пришлось перезапускать webcallserver, причем с ручным убийством процесса java. После этого заработало. Сейчас запущу тест еще раз, интересно повторится или нет.

P.S. Также один момент. Во время трансляции есть заметные "фризы", довольно-таки частые. Я не знаю, может быть это конечно связано с тем, что всё это на одном канале происходит. Нагрузка на cpu у Flashphoner-сервера не превышает 30% во время трансляции.

 

[alexanderY]

Повторил тест, на этот раз 20 минут нагрузки. По окончанию также всё отвалилось, пришлось перезагружать webcallserver.

 

[Max]

ок. проверим у себя. скорее всего в понедельник-вторник.

 

[alexanderY]

Добрый вечер. Удалось ли воспроизвести проблему?

 

[Max]

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

 

[Max]

Добрый день.
В последних версиях сервера 2154 эту проблему исправили.
Нагрузочное тестирование прошло успешно.

 

[alexanderY]

Здравствуйте.
Обновились.
Первый тест прошел хорошо. Нагрузка не скачет. После завершения теста никто не отвалился.
Второй тест уже странновато. Параметры теста не менялись. Та же комната, 2 стримера, 30 зрителей, 20 минут.
Всё время, пока шёл тест, проблем не было. Нагрузка на сеть была 30-32 мбит/сек. Через 20 минут, однако, процессы chrome начали умирать, но нагрузка на сервер не падала. Визуально проблем тоже не было - оба стримера друг друга видели, по крайней мере. Тогда я решил обновить страницу стримера и посмотреть, что будет. Нагрузка стала сильно расти, как раньше. Потом упала до 15 мбит/сек. Стример подключился к комнате, хоть и не сразу.
Затем я обновил страницу на втором стримере. Точно такое же поведение. На скриншоте удалось запечатлеть 123 мбит/сек: https://yadi.sk/i/TaWwYQcp3GSPjn. В консоли браузера видел, что к комнате подключено 30 пользователей. Затем подключение оборвалось. В консоли браузера "Error: Invalid session state". Повторно подключиться не удалось. Перезагружаемся.

 

[Max]

Проведем еще серию тестов. По результатам отпишу.

 

[alexanderY]

Какие-то логи с нашей стороны могут помочь? Тоже сейчас тестим. На разных серверах. Я сохраню, выложу, если надо.

Один момент, до меня только недавно дошло. Откуда вообще мог взяться трафик в 150+ мбит на сервере, если мой домашний канал всего 50 мбит? Хоть ты тресни, я не смогу выкачивать больше, сколько ботов не запускай.

 

[Max]

Пока нет. Нам удалось воспроизвести проблему.
Этот тест дает стрессовую нагрузку на механизм Keep Alive.
В нормальном тестировании, как правило, пользователи закрывают вкладки браузера и сервер их дисконнектит. Keep Alive не требуется.
В xload - тестировании, процессы Chrome жестко убиваются, поэтому все дисконнекты работают на основе Keep Alive. И там мы нашли проблему. В результате идет рост памяти и выход по памяти. Если сможете приложить похожую картинку, было бы интересно получить подтверждение:

Visual VM

Один момент, до меня только недавно дошло. Откуда вообще мог взяться трафик в 150+ мбит на сервере, если мой домашний канал всего 50 мбит? Хоть ты тресни, я не смогу выкачивать больше, сколько ботов не запускай.

Да, выкачать вы не можете. Канал не позволит.
Трафик этот берется от ретрансмитов.
Пример:
1. WCS отправляет браузеру видеопакет 1400 байт.
2. Пакет не доходит до браузера, как раз по причине того, что канал забит.
3. Браузер отправляет запрос на ретрансмит: 100 байт.
4. WCS отправляет браузеру видеопакет 1400 байт.
и т.д.
В обратную сторону канал свободен, поэтому ваши запросы, условно в 100 байт, доходят до WCS.
А по направлению к браузеру скапливается пробка, т.к. там досылаются уже тяжелые видео пакеты.
В итоге видим такой burst в 150 Mbps.

 

[Max]

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

 

[alexanderY]

Сегодня удалось пару часов потестировать, завтра контрольный тест.
Описанный выше баг повторить не удалось, все работало стабильно. Было 60-65 ботов-зрителей и 2 стримера. Единственный момент, я ставил большой ttl, чтобы боты не умирали. Потом в конце теста зарубил процессы Хрома. В этот момент стримеры потеряли коннект, даже рефреш страницы не помогал. Спустя пару минут коннект снова появился, хотя я ничего не делал. Половина ботов была с моей машины, другая половина с виртуалки в совершенно другой сети.

 

[alexanderY]

Сегодня конкретно так потестили. Было две виртуалки с xload, плюс в первых тестах еще с моей машины часть ботов. Впечатления положительные. Аномалий по трафику вообще не было. Сборка 2158.

1. Первые тесты 2 стримера, 90 ботов. Все ок, но когда я с "контрольной" машины в качестве зрителя обновлял страницу, не сразу удавалось подключиться. Задержка в несколько секунд, но это очень даже неплохо, по личным ощущениям.
Однако если стример обновит страницу, то сервер не рассылает клиентам сообщение о том, что стример покинул комнату. Из-за этого клиенты считают, что стрим реально есть, а сам стример не может подключиться пару минут. Потом коннект все-таки происходит, без вмешательства админа. Впрочем, это поведение вроде бы получилось побороть. Я увеличил время между попытками реконнекта. Было 5 секунд, стало 10 — и несколько раз подряд разные стримеры обновляли страницу, проблем не было. Пишу просто для информации — т.к. на данный момент проблема решена, действий тут не требуется.

Есть идея на клиенте ловить событие onbeforeunload / onunload и посылать дисконнект Флэшфонеру. А также при загрузке страницы не сразу подключаться, а сделать искусственную задержку 1-2 секунды. Интересно ваше мнение. Цель - избавить сервер от ситуаций, когда он считает, будто один и тот же юзер подключается множество раз.

2. Следующий тест - 5 параллельных комнат, в каждой по 2 стримера, и больше никаких юзеров. Все было отлично вообще, нагрузка низкая, багов не заметили.

3. Опять вернулись в одну комнату. Сделали 3 видео стрима и 3 аудио, и 30 зрителей. Тут уже были странные баги. Через 10-20 минут несколько раз отключало вообще всех стримеров. Пару раз отключало половину стримеров. Во всех случаях спустя пару минут коннект восстанавливался. Т.е. сервер не падал. Нагрузка на процессор была 30-35% максимум. Может в пиках выше, но средняя именно такая. По памяти было очень мало free памяти, но несколько гигабайт cache. Причем, чем больше стримеров, тем меньше free и больше cache.

Нужны ли вам какие-то логи в помощь? Если удастся хотя бы выяснить причину, почему периодически отключает всех, будет очень круто. Visual VM пока не ставил, руки не дошли.

 

[Max]

Есть идея на клиенте ловить событие onbeforeunload / onunload и посылать дисконнект Флэшфонеру. А также при загрузке страницы не сразу подключаться, а сделать искусственную задержку 1-2 секунды. Интересно ваше мнение. Цель - избавить сервер от ситуаций, когда он считает, будто один и тот же юзер подключается множество раз.

Если пользователь неожиданно теряет коннект к серверу, то включаются keep alive.
Если поднимать их значение, например 10 проб по 6 секунд, то сервер будет держать пользователя 60 секунд в памяти.
Если уменьшить их значение, например 2 пробы по 2 секунды, то сервер будет держать пользователя 4 секунды в памяти. Но в этом случае быстрее будут происходить разрывы, например, если канал перегружен видео трафиком, keep alive могут не пройти и выйти за эти 4 секунды.
Пример из server.properties

keep_alive.server_interval =5000
keep_alive.probes =10

Т.е. если настроить keep alive на минимальное время 4 секунды, а реконнект делать через 5-10 секунд, то все должно отрабатывать корректно.

Если используете комнаты, то идеально было бы использовать уникальный генерируемый login для каждого подключения. В этом случае, если пользователь abc отвалился, можно было сразу коннектить этого же пользователя под логином def, при этом abc был бы зачищен в нормальном режиме.

Опять вернулись в одну комнату. Сделали 3 видео стрима и 3 аудио, и 30 зрителей. Тут уже были странные баги. Через 10-20 минут несколько раз отключало вообще всех стримеров.

Стримеры и все плееры (30 x 3=90) были на одном канале?
Если на одном, то стримеры могут отваливаться по причине нехватки канала на Download. Установленный WebRTC-канал поддерживается внутренними UDP / STUN keep alive. Если канал забит, эти сообщения не проходят и WebRTC-каналы стримеров и / или плееров начинают отваливаться.

 

[alexanderY]

Т.е. если настроить keep alive на минимальное время 4 секунды, а реконнект делать через 5-10 секунд, то все должно отрабатывать корректно.

keepalive был настроен на минимальное время, как вы раньше предлагали попробовать. Реконнект был через 5 секунд. Увеличили вчера до 10, вроде бы стало получше. В общем, это вроде не критичный момент. Думал про уникальные логины, но по-быстрому это не реализовать, т.к. логины юзеров это id в нашем приложении. Завязано на бизнес-логику. Так что эту идею пока отложил.

Стримеры и все плееры (30 x 3=90) были на одном канале?

Плееры на отдельном канале. Три стримера на одном канале, три стримера на другом. Не обратил внимания, какие стримеры именно отвалились, но вроде бы отваливались разные. Т.е. один раз могли отвалиться юзеры 1,2,3, другой раз 1,4,5. Впрочем, следующий этап это пробовать на реальных юзерах, когда на одном канале один стрим, и смотреть уже.

 

[Max]

В последних сборках мы отладили работу с адаптивным битрейтом.

webrtc_cc2=true

Эта настройка включена по-умолчанию, начиная со сборки 2158.
Нужно убедиться что в flashphoner.properties что она не переопределяется в false.

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

 

[alexanderY]

У нас как раз 2158, в flashphoner.properties вообще пока не прописывали ни webrtc_cc2, ни webrtc_cc2_min_remb_bitrate_bps. Я что-то не уверен, что из-за одного зрителя должны страдать остальные, так что ничего страшного не должно случиться, если отключить эту настройку?

В пятницу провели небольшое мероприятие на 10 юзеров (т.е. нагрузка была небольшая). Произошло две вещи:

1. Разных стримеров отрубало через несколько минут после начала вещания. Здесь не уверен, возможно связано с нашей логикой, так что пожалуйста все внимание на пункт 2.
2. Один из стримеров остался в комнате. Флэшфонер считает, что он до сих пор (!) там и стримит, хотя юзера реально нет. Перефразируя.. юзер закрыл браузер, выключил ноутбук в пятницу. Я в понедельник захожу в комнату и вижу, будто бы идет стрим. При этом юзер оффлайн.

Вопрос, что означает ошибка NOT_ENOUGH_BANDWIDTH в файле flashphoner_manager.log? На стороне юзера недостаточно канала, или на стороне сервера? На сервере у нас 300 мбит, так что сомневаюсь. В пятницу было довольно много таких ошибок, но связано в основном с двумя юзерами (часто повторяется ошибка), и еще с двумя (редко). При этом ни один из этих юзеров не является проблемным юзером из пункта 2.