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

Оптимизация сервера

потокового видеовещания

Дмитрий Шатров

Мой Мир@Mail.Ru

трансляции

видеочат

http://momentvideo.org

Трансляции@mail.ru

В поисковой выдаче

Сервис трансляций

Сервис трансляций

Потоковое видео

Трансляции

Конференции

Видеочат

...и не только

Организация сервиса

Центральный сервер

Мультикаст

P2P

Центральный сервер

сервер

Мультикаст

сервер

P2P

сервер

Центральный сервер

Основа видеосервиса

сервер

Сервер видеочата

2 тыс. одновременно подключенных клиентов

Два видеопотока ~250 Кбит/сек на клиента

Горизонтальное масштабирование

3 независимых сервера, ~350 Мбит/сек на сервер, загрузка CPU не больше 25%

Сервер трансляций

5 тыс. одновременно подключенных клиентов

Один видеопоток 200-500 Кбит/сек на клиента

Кластер из трёх раздающих серверов и одного арбитра

Очень неравномерная нагрузка на серверы

Характер нагрузки

Нагрузка быстро скачет с одного сервера на другой.

Трансляций с кол-вом зрителей >100 обычно не больше 10 штук.

Нужно разносить популярные трансляции по нескольким серверам.

Шторм подключений

Рестарт сервера — реконнект всех клиентов.

Moment отлично справляется с толпой клиентов, пришедших одновременно.

Реконнект работает хорошо, на это можно рассчитывать при перебалансировке.

1 ∞

Видеосервер

Бизнес-логика

отдельные сообщения

RTMP

видеопоток

API

Клиент подключился

Клиент отключился

Запрос на просмотр

Запрос на вещание

RPC

Протокол RTMP

Нужен для взаимодействия с Flash

2 уровня: chunk stream и message stream

поддержка RPC

RTMPT — RTMP поверх HTTP

Переусложнён, спецификация неточна

Реализация RTMP

~1,5 месяца работы одного разработчика

изучение протоколареализацияотладкаоптимизация

+ RTMPT

Принцип работы

event-машина на неблокирующихся сокетах

Получение данных

Отправка данных

Оптимизация

Стараемся максимально эффективно использовать примитивы, предлагаемые ядром.

Минимизируем количество системных вызовов для отправки данных.

Хотим ускориться в несколько раз.

Немедленная отправка

При отправке сообщение либо уходит целиком,либо мы заключаем, что клиент медленный и начинаем отбрасывать сообщения.

В результате writev работает только в рамках одного сообщения.

Отложенная отправка

За одну операцию чтения в приёмный буфер может быть считано сразу несколько сообщений.

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

Отправляем все считанные за итерацию данные одним writev.

В конце итерации

mwritev

Простой модуль ядра: /dev/mwritev

Принимает массив наборов параметров для вызовов writev

Вызывает vfs_writev для каждого набора параметров

Возвращает массив результатов

mwritev

-15% нагрузки на CPU

Это немного. Значит, контекстные переключения относительно недороги.

Дальнейшая оптимизация снижает эффект от использования mwritev.

Группировка сообщений

Равномерный видеопоток => интервалы между сообщениями препятствуют группировке.

Тестовый модуль Moment — mod_test. Генерирует поток сообщений.

rtmptool — имитирует N одновременных подключений.

Группировка сообщений

burst = 3 => производительность x 2.5

Группировать сообщения очень выгодно.

Группировка сообщений

Задерживаем помещение клиента в очередь отложенной отправки, если в очереди только аудио и видео сообщения, и с момента последней отправки прошло меньше M миллисекунд.

Т.е. буферизуем поток на сервере, вводим искуственную задержку.

Эффект от группировки

Видео ~560 Кбит/секPentium 4, 2.8 ГГц (low-end сервер)

задержка 0 мс — 1400 клиентов

задержка 100 мс — 3500 клиентов

задержка 500 мс — 5000 клиентов

Эксперимент

Добиваемся 100%-й загрузки CPU и продолжаем увеличивать кол-во подключений.

Видимого ухудшения качества видео при просмотре не происходит. Немного растёт задержка (но не превышает 1 сек).

Первые пропуски видео/звука — на 6000 клиентов.

?CPU — 100%

Саморазгон сервера

CPU 100% => следующая итерация цикла обработки сообщений начнётся позже.

На следующей итерации будет доступно больше данных от источника видео.

В конце итерации мы отправим больше данных. Т.е размер отправляемой за раз порции данных вырастет.

Саморазгон сервераЧем больше размер блока данных при отправке, тем выше производительность сервера.

Получаем эквивалент динамического увеличения задержки при отправке в зависимости от нагрузки на сервер.

Порог в 6000 клиентов согласуется с эффектом от явной буферизации.

Многопоточность

В Moment:

Отдельная блокировка на каждый крупныйобъект (мьютекс)

Подсчёт ссылок

- 25% производительности даже с однимпотоком

Многопоточность

Сложно писать

Сложно отлаживать

Сервер медленнее

Но есть свои плюсы

Итог

Архитектура «боевого» видеосервера.

3 тыс. клиентов с одного ядра на low-end системе (500 Кбит/сек на клиента).

До 6 тыс. клиентов на пике при умеренном увеличении задержки.

Реализованы все описанные оптимизации.

Умеет всё, что нужно для таких сервисов, как трансляции, видеочат и им подобные.

Захват видео с камер, видеонаблюдение, запись.

Открытый код. API для плагинов.

http://momentvideo.org