Кэширование в Amazon CloudFront для потоковой передачи HLS/HDS с помощью Wowza 3.5

Я пытаюсь быстро изучить некоторые основные технологии, лежащие в основе прямой трансляции HDS и HLS.

Я настроил сервер Wowza Media 3.5 на экземпляре Amazon WebServices в EC2 и распространяю его через CloudFront. Я провел свое первое живое мероприятие и наблюдал, как нагрузка на мой сервер растет все выше и выше. Мне было интересно, может ли кто-нибудь помочь мне понять некоторые основы потокового вещания HDS/HLS (и nDVR...):

  • Wowza — исходный сервер для моего облачного дистрибутива.
  • Файл манифеста HDS настроен на кэширование в течение 2 секунд в CF (время TTL)
  • Я проверил все IP-адреса, попадающие в мой экземпляр Wowza, на самом деле они оказались местами кэширования CF или пограничными серверами.
  • (предположение) Поскольку весь трафик HDS проходит через порт 80, весь видеоконтент в конечном итоге кэшируется на периферии (хотя и на 2 секунды).

Вот где возникает мой вопрос: как данные обслуживаются для видеоконтента (вот мое понимание, пожалуйста, поправьте меня!): - Когда зритель запрашивает плейлист или файл основного фестиваля, он возвращает XML, который указывает проигрывателю на фрагмент видео /audio (m4fa и m4fv в экземпляре приложения DVR?), которые им нужно воспроизвести дальше. Поскольку эти данные также доставляются через порт 80, они также кэшируются.

Если приведенные выше утверждения верны, то имеет ли смысл следующее для оптимизации для HDS и HLS:

Случай 1: Сервис видеорегистратора: я установил правила кэширования в CloudFront следующим образом:

  • все, что заканчивается на "f4m", "m3u8" и "?DVR" для кэширования на 2 секунды (файлы списка воспроизведения/манифеста)
  • по умолчанию все остальное должно кэшироваться дольше (возможно, час или 24 часа...?). Таким образом, данные DVR остаются в кэше, но список воспроизведения продолжает обновляться каждые 2 секунды.

Случай 2: Нет службы DVR (это лучший способ оптимизации?)

  • Я подозреваю, что мы могли бы также оптимизировать нагрузку на сервер, полностью отключив службу DVR, таким образом, все данные, распространяемые через CF, представляют собой только самые последние аудио/видео пакеты, поэтому все зрители должны запрашивать один и тот же список воспроизведения и файлы данных, и, следовательно, большое количество людей, запрашивающих эти файлы, не имеет большого значения, поскольку мой сервер обновляется только каждые 2 секунды из каждого пограничного местоположения для обновления файлов манифеста).
  • Если фрагментам медиафайлов дается более длительное время кэширования, будет ли иметь значение, отключим ли мы службу DVR, если медиафайлы останутся в кэше?

Спасибо за любую информацию, которую вы можете предложить!


person dcoffey3296    schedule 07.12.2012    source источник
comment
Я думаю, вы понимаете это правильно. У меня только один вопрос - возможно ли, что кеширование испортилось из-за наличия идентификатора сеанса в URL-адресах?   -  person vipw    schedule 13.12.2012
comment
Да, vipw, именно такое поведение я и наблюдаю. В настоящее время я ищу в документации способ отключить эти уникальные идентификаторы сеансов, если у вас есть какие-либо идеи! Спасибо за предложение!   -  person dcoffey3296    schedule 13.12.2012
comment
Я думаю, вам нужно использовать подход в стиле push. У вас может быть сценарий, который инициализирует сеанс из Wowza и передает то, что он читает, на S3, который читает CloudFront. Но я не пользовался Wowza пару лет, может у них есть решение получше. Вы спрашивали на их форуме? Они чрезвычайно полезны в моем опыте.   -  person vipw    schedule 13.12.2012


Ответы (1)


Есть ли способ настроить другое имя сайта для медиа? Для сеансов DVR вы хотите, чтобы файлы m3u8 обслуживались непосредственно с вашего сервера (без CF или 2-секундного CF), но медиафайлы обслуживались через CloudFront с очень длительным сроком действия.

(Для сеансов без DVR все это может проходить через CloudFront, поскольку оно кэшируется.)

Полезность CloudFront действительно зависит от того, сколько у вас популярных (и непопулярных) потоков.

Например, предположим, что в определенной точке присутствия есть 20 ящиков CloudFront. Если 5 человек просматривают поток, каждый из них, вероятно, попадет в свой блок CF, получит промах кеша и все равно должен будет попасть на ваш сервер. Вам нужно, чтобы 50 или 70 человек просматривали поток с этой точки присутствия, прежде чем CloudFront перестанет поражать ваш сервер и будет обслуживать все из кеша. Поскольку существует много точек присутствия, у вас может быть 100 человек, которые просматривают поток по всему миру, но каждый нажимает на разные поля в разных точках присутствия, и ваш сервер все равно получает 100 запросов.

person BraveNewCurrency    schedule 07.05.2013
comment
Спасибо за ответ. Вы уверены, что это так и что мы увидим преимущества CF после 100+ пользователей? Нет ли способа убедиться, что пользователи просто нажимают на одно и то же поле CF? Потому что, если нет, трудно проверить, работает ли он. - person sbaar; 30.03.2016
comment
Я говорю, что если у вас небольшое количество пользователей, CF не облегчит нагрузку на ваш вышестоящий сервер. (Возможно, использование CF по-прежнему имеет смысл из-за сетевых причин.) Обратите внимание, что AWS предоставляет вам статистику попаданий в кэш, чтобы вы могли убедиться, что он работает. - person BraveNewCurrency; 06.04.2016