O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Оптимизация сервера потокового видеовещания (Дмитрий Шатров)

  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

Оптимизация сервера потокового видеовещания (Дмитрий Шатров)

  1. 1. Оптимизация серверапотокового видеовещания Дмитрий Шатров
  2. 2. Мой Мир@Mail.Ru трансляции видеочат http://momentvideo.org
  3. 3. Трансляции@mail.ru
  4. 4. В поисковой выдаче
  5. 5. Сервис трансляций
  6. 6. Сервис трансляций
  7. 7. Потоковое видеоТрансляцииКонференцииВидеочат ...и не только
  8. 8. Организация сервисаЦентральный серверМультикастP2P
  9. 9. Центральный сервер сервер
  10. 10. Мультикаст сервер
  11. 11. P2Pсервер
  12. 12. Центральный сервер серверОснова видеосервиса
  13. 13. Сервер видеочата2 тыс. одновременно подключенных клиентовДва видеопотока ~250 Кбит/сек на клиентаГоризонтальное масштабирование3 независимых сервера, ~350 Мбит/сек насервер, загрузка CPU не больше 25%
  14. 14. Сервер трансляций5 тыс. одновременно подключенных клиентовОдин видеопоток 200-500 Кбит/сек на клиентаКластер из трёх раздающих серверов и одногоарбитраОчень неравномерная нагрузка на серверы
  15. 15. Характер нагрузкиНагрузка быстро скачет с одного сервера надругой.Трансляций с кол-вом зрителей >100 обычноне больше 10 штук.Нужно разносить популярные трансляции понескольким серверам.
  16. 16. Шторм подключенийРестарт сервера — реконнект всех клиентов.Moment отлично справляется с толпойклиентов, пришедших одновременно.Реконнект работает хорошо, на это можнорассчитывать при перебалансировке.
  17. 17. 1 ∞
  18. 18. Видеосервер RTMP отдельные сообщениявидеопоток Бизнес- логика
  19. 19. APIКлиент подключилсяКлиент отключилсяЗапрос на просмотрЗапрос на вещание RPC
  20. 20. Протокол RTMPНужен для взаимодействия с Flash2 уровня: chunk stream и message streamподдержка RPCRTMPT — RTMP поверх HTTPПереусложнён, спецификация неточна
  21. 21. Реализация RTMP~1,5 месяца работы одного разработчика изучение протокола реализация отладка оптимизация + RTMPT
  22. 22. Принцип работыevent-машина на неблокирующихся сокетах
  23. 23. Получение данных
  24. 24. Отправка данных
  25. 25. ОптимизацияСтараемся максимально эффективноиспользовать примитивы, предлагаемые ядром.Минимизируем количество системных вызововдля отправки данных.Хотим ускориться в несколько раз.
  26. 26. Немедленная отправкаПри отправке сообщение либо уходит целиком,либо мы заключаем, что клиент медленный иначинаем отбрасывать сообщения.В результате writev работает только в рамкаходного сообщения.
  27. 27. Отложенная отправкаЗа одну операцию чтения в приёмный буферможет быть считано сразу несколькосообщений.Откладываем отправку данных до концаитерации цикла обработки сообщений.Отправляем все считанные за итерациюданные одним writev.
  28. 28. В конце итерации
  29. 29. mwritevПростой модуль ядра: /dev/mwritevПринимает массив наборов параметров длявызовов writevВызывает vfs_writev для каждого наборапараметровВозвращает массив результатов
  30. 30. mwritev-15% нагрузки на CPUЭто немного. Значит, контекстныепереключения относительно недороги.Дальнейшая оптимизация снижает эффект отиспользования mwritev.
  31. 31. Группировка сообщенийРавномерный видеопоток => интервалы междусообщениями препятствуют группировке.Тестовый модуль Moment — mod_test.Генерирует поток сообщений.rtmptool — имитирует N одновременныхподключений.
  32. 32. Группировка сообщенийburst = 3 => производительность x 2.5Группировать сообщения очень выгодно.
  33. 33. Группировка сообщенийЗадерживаем помещение клиента в очередьотложенной отправки, если в очереди толькоаудио и видео сообщения, и с моментапоследней отправки прошло меньше Mмиллисекунд.Т.е. буферизуем поток на сервере, вводимискуственную задержку.
  34. 34. Эффект от группировкиВидео ~560 Кбит/секPentium 4, 2.8 ГГц (low-end сервер)задержка 0 мс — 1400 клиентовзадержка 100 мс — 3500 клиентовзадержка 500 мс — 5000 клиентов
  35. 35. ЭкспериментДобиваемся 100%-й загрузки CPU ипродолжаем увеличивать кол-во подключений.Видимого ухудшения качества видео припросмотре не происходит. Немного растётзадержка (но не превышает 1 сек).Первые пропуски видео/звука — на 6000клиентов.
  36. 36. ?CPU — 100%
  37. 37. Саморазгон сервераCPU 100% => следующая итерация циклаобработки сообщений начнётся позже.На следующей итерации будет доступнобольше данных от источника видео.В конце итерации мы отправим большеданных. Т.е размер отправляемой за разпорции данных вырастет.
  38. 38. Саморазгон сервераЧем больше размер блока данных приотправке, тем выше производительностьсервера.Получаем эквивалент динамическогоувеличения задержки при отправке взависимости от нагрузки на сервер.Порог в 6000 клиентов согласуется сэффектом от явной буферизации.
  39. 39. МногопоточностьВ Moment: Отдельная блокировка на каждый крупный объект (мьютекс) Подсчёт ссылок - 25% производительности даже с одним потоком
  40. 40. МногопоточностьСложно писатьСложно отлаживатьСервер медленнееНо есть свои плюсы
  41. 41. ИтогАрхитектура «боевого» видеосервера.3 тыс. клиентов с одного ядра на low-endсистеме (500 Кбит/сек на клиента).До 6 тыс. клиентов на пике при умеренномувеличении задержки.
  42. 42. http://momentvideo.orgРеализованы все описанные оптимизации.Умеет всё, что нужно для таких сервисов, кактрансляции, видеочат и им подобные.Захват видео с камер, видеонаблюдение, запись.Открытый код. API для плагинов.

×