Owncast перед мероприятием: как провести нагрузочную репетицию трансляции

Сначала забудьте про цифру «нас зарегистрировалось две тысячи». Для сервера она почти ничего не значит. Важно другое: сколько людей будут смотреть эфир одновременно в самый напряжённый момент, например в первые пять минут после объявления начала или во время розыгрыша. Из двух тысяч регистраций одновременно могут прийти и триста, и тысяча, а могут и все сто, если мероприятие идёт в рабочий вторник. Поэтому репетиция начинается не с запуска утилит, а с честной оценки пика и с вопроса, что именно вы собираетесь проверять.

Ниже разобран порядок, который позволяет к дню события получить собственное, подтверждённое опытом число: сколько зрителей ваш Owncast на выбранном VPS выдерживает при выбранном качестве видео. Готового числа «на тариф» здесь не будет, и это сознательно: оно зависит от битрейта, числа вариантов качества, географии зрителей и их устройств.

Три разных вида работы в одном эфире

Когда говорят «сервер не тянет», обычно смешивают три разные нагрузки. Их полезно разделить, потому что у каждой свой ресурс и свой признак перегрузки.

1. Приём потока. Кодировщик на стороне ведущего (OBS или другая программа) отправляет видео на сервер. Это один входящий поток, он не растёт с числом зрителей.
2. Подготовка вариантов качества. Сервер перекодирует входящее видео в один или несколько вариантов. По документации Owncast перекодирование вариантов расходует CPU, и важный нюанс: кодирование варианта не запускается заново для каждого зрителя. Сто зрителей не означают сто перекодирований.
3. Выдача зрителям. Каждый зритель непрерывно скачивает видеосегменты. Здесь расходуется исходящая полоса, а также небольшие, но реальные ресурсы на обслуживание самих соединений.

Отсюда следует главное правило репетиции: нагрузка первого и второго вида определяется настройками эфира и почти не меняется, пока идёт трансляция, а нагрузка третьего вида растёт вместе с аудиторией. Поэтому процессор вы можете проверить ещё до прихода первого зрителя, а исходящий канал — только добавляя зрителей ступенями.

Выбираем битрейт и длительность опыта

Репетиция на красивой тестовой картинке с низким битрейтом даст красивое и бесполезное число. Опыт должен идти на тех настройках, с которыми вы действительно выйдете в эфир: то же разрешение, та же частота кадров, тот же битрейт, тот же набор вариантов качества. Руководство по качеству видео напоминает, что число вариантов, разрешение, частота кадров и битрейт влияют на затраты ресурсов, и советует начинать с одного варианта, проверяя работу прежде, чем добавлять другие. Для репетиции это удобный порядок: сначала один вариант, потом второй, и вы видите, во что обходится каждое добавление.

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

Длительность опыта нужна не меньше эфира по масштабу. Короткий пятиминутный тест показывает пиковую картину, но не покажет проблем, которые копятся: рост использования памяти, заполнение диска сегментами, постепенное нарастание задержки. Разумный минимум: по двадцать–тридцать минут на каждой ступени нагрузки в сумме с общим прогоном, близким по длине к реальному эфиру. Если эфир идёт три часа, хотя бы один раз проведите тест такой же длины или близкой к ней, а не склеивайте выводы из пятиминуток.

Расчёт полосы: где заканчивается «хватит интернета»

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

Возьмём условный пример для наглядности, это не результат измерения. Пусть основной вариант идёт на 2,5 Мбит/с, а на пике ожидается 400 одновременных зрителей, и все смотрят его.

Видно, что 400 зрителей на таком битрейте уже упираются в гигабит, а с запасом выходят за него. И это без учёта того, что часть аудитории может смотреть вариант покрупнее. Из таблицы следуют два практических вывода.

• Если в тарифе вашего VPS заявлена конкретная скорость порта, сравнивайте с ней именно расчётную полосу, а не «мегабайты трафика в месяц». Важна мгновенная пропускная способность на пике, а не только суммарный объём.
• Снижение битрейта вдвое увеличивает вместимость по каналу примерно вдвое. Это самый дешёвый рычаг: иногда лучше отдать зрителям 1,5 Мбит/с стабильно, чем 3 Мбит/с с буферизацией.

Если вы добавляете низкий вариант качества (скажем, 0,8 Мбит/с для мобильных зрителей), расчёт меняется: считайте отдельно, какая доля аудитории будет на каком варианте. Часть людей с плохим соединением переключится вниз сама, и это снизит нагрузку на канал, но повысит нагрузку на CPU, ведь вариантов теперь два.

Эти числа нужны не как обещание, а как гипотеза для проверки. Если ваш расчёт говорит «упрёмся в канал на 300 зрителях», репетиция должна либо подтвердить эту границу, либо показать, что узким местом оказалось что-то другое.

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

Не пытайтесь сразу выйти на пиковую цифру. Идите ступенями, например: 10, 25, 50, 100, 200 зрителей, и на каждой ступени держите нагрузку достаточно долго, чтобы показатели стабилизировались. На каждой ступени записывайте две группы наблюдений одновременно.

Со стороны сервера: загрузка CPU (общая и по ядрам), использование памяти, исходящая скорость сетевого интерфейса, число соединений, свободное место на диске.

Со стороны просмотра: что видит человек. В Owncast есть раздел метрик, где показатели Stream Performance включают скорость загрузки видеосегментов, ошибки, переключения качества и задержку зрителя. Оговорка, которую стоит запомнить: не все проигрыватели передают эти сведения, поэтому пустой график не равен хорошему просмотру. Часть сведений придётся добирать глазами.

Практичнее всего завести двух-трёх живых наблюдателей на разных сетях: проводной интернет, домашний Wi-Fi, мобильная сеть. Пусть они не просто «смотрят», а записывают время, когда картинка замирает, когда появляется кружок буферизации, когда звук рассинхронизируется с видео. Сервер может показывать зелёные цифры, пока у зрителя картинка спотыкается, потому что узким местом оказался чей-то маршрут или сам проигрыватель.

Чем искусственные зрители отличаются от настоящих

Для создания массовой нагрузки обычно используют скрипты или утилиты, которые открывают много соединений и скачивают сегменты. Это полезный инструмент, но надо ясно понимать его границы. Такая симуляция проверяет, выдержит ли сервер и канал поток запросов. Она не проверяет человеческий просмотр: не показывает, как поведёт себя конкретный браузер на старом телефоне, как проигрыватель выберет вариант качества, как отреагирует на потерю пакетов домашний роутер, как отработает чат при одновременных сообщениях. Скрипт не расстраивается, не обновляет страницу и не пишет «у меня лагает».

Если нагрузка идёт с той же машины, на которой стоит Owncast, или из того же дата-центра, результат тоже будет оптимистичным: путь до сервера короткий и чистый. Генерируйте нагрузку из другой сети, а лучше из нескольких. И обязательно проверьте, что сам источник нагрузки не упирается в свой канал, иначе вы измерите его потолок, а не потолок сервера.

Честная формулировка результата такая: «сервер и канал выдержали N имитированных соединений, а живые наблюдатели из таких-то сетей видели такую-то картину». Не «мы проверили на N зрителей», пока среди них не было настоящих людей.

Что упёрлось: процессор или канал

Самое полезное, что даёт репетиция, — умение отличать два разных диагноза, потому что лечатся они по-разному. Мы уже разложили нагрузку: CPU отвечает за перекодирование, канал отвечает за выдачу. Теперь смотрим на симптомы.

Характерный признак «полки» на графике исходящей скорости стоит запомнить: если при росте зрителей кривая упирается в ровную горизонталь и дальше не растёт, а проблемы у зрителей продолжаются, вы нашли предел канала. Если же процессор прижат к потолку ещё до прихода зрителей, дальнейшие ступени бессмысленны: вы не успели начать, а кодировщик уже на пределе. Сначала упростите кодирование, затем продолжайте.

Возможен и смешанный случай: на малых ступенях всё хорошо, на средних процессор начинает подниматься из-за обслуживания соединений (это те самые дополнительные расходы на зрителей, которые документация отдельно оговаривает), а на больших включается ещё и канал. Тогда граница определяется тем, что наступит раньше, и записывать надо именно её.

Как ресурсы плана связаны с этими диагнозами

На VPS MAATRIX доступны ступени от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) до Djed (16 vCPU, 32 ГБ, 320 ГБ), промежуточные: Uab, Heka, Maat. Вычислительные ядра влияют на запас по перекодированию, поэтому, если репетиция показала, что CPU упирается раньше канала, разумно пробовать тариф с большим числом vCPU. Если же упёрлись в канал, дополнительные ядра ничего не дадут: нужно менять битрейт или схему раздачи. Это отправная точка для теста, а не обещание вместимости: характеристики плана показывают, с чего начинать, а границу всё равно определяет ваш замер. Из-за root-доступа удобно ставить на машину наблюдение за процессами и сетью и снимать картину прямо во время испытания. Полезно также проверить репетицией ту локацию, в которой вы будете запускать эфир (в публичном предложении перечислены UK, US, RU и FR): маршрут до ваших зрителей зависит от того, где стоит сервер.

Остановочные критерии: когда ступень считается проваленной

Без заранее выписанных критериев репетиция превращается в обсуждение ощущений. Договоритесь до начала, при каких признаках вы прекращаете повышать нагрузку и фиксируете предыдущую ступень как предел. Пример такого набора (числа подставьте свои):

• загрузка CPU держится выше заранее выбранной доли (например, выше 85–90%) дольше нескольких минут;
• исходящая скорость вышла на полку, а число зрителей с жалобами на буферизацию растёт;
• в метриках заметен рост ошибок загрузки сегментов или частые переключения качества вниз (если ваши проигрыватели эти данные передают);
• задержка зрителя заметно растёт со временем, а не держится на одном уровне;
• кто-то из живых наблюдателей фиксирует остановки картинки чаще оговорённого порога.

Последний пункт важен: это ваш человеческий критерий, и он не должен подменяться только машинными показателями. Если на 150 имитированных зрителях графики спокойны, а два из трёх живых наблюдателей видят зависания, предел ниже, чем показывает сервер.

Итоговую вместимость определяйте с запасом. Если ступень в 200 зрителей прошла на грани, не объявляйте 200 рабочим числом: рабочим будет та ступень, где остался заметный запас, скажем, 150. День мероприятия приносит то, чего не было в репетиции: ведущий забыл снизить битрейт, кто-то открыл эфир на трёх устройствах, у части аудитории общая проблема с провайдером.

Начало мероприятия: самое тяжёлое пять минут

Равномерный набор зрителей на репетиции редко похож на реальность. На мероприятии люди приходят пачкой: рассылка ушла, таймер дошёл до нуля, и сотни браузеров открывают страницу почти одновременно. Поэтому отдельным опытом проверьте резкий старт: за минуту подключите ту ступень, которую вы считаете рабочей. Именно здесь проявляются перегрузки, которых не видно при плавном росте: очередь соединений, скачок CPU на обслуживании, перегрузка веб-интерфейса и чата.

Смягчить пик можно организационно, и это стоит делать, если репетиция показала узкое место. Откройте страницу ожидания за 10–15 минут до начала и сообщите об этом в анонсе, чтобы часть зрителей пришла заранее. Поставьте на странице заставку или предстартовый отсчёт, чтобы люди уже были подключены, когда пойдёт основной эфир. Это не техническая хитрость, а перераспределение нагрузки во времени, и оно часто дешевле, чем повышение тарифа.

Источник упал: проверяем возвращение

Вторая половина репетиции, о которой забывают, — сценарий сбоя на стороне ведущего. Интернет ведущего мигнул, OBS завис, компьютер перезагрузился. Важно не только то, что эфир прервётся, а то, как он вернётся. Проверьте на репетиции по шагам:

1. Во время ступени с заметным числом зрителей намеренно остановите поток на источнике.
2. Посмотрите, что видят зрители: понятное состояние «эфир приостановлен» или бесконечная пустота.
3. Запустите поток снова с теми же настройками и засеките время до появления картинки у зрителей.
4. Проверьте, не пришлось ли зрителям обновлять страницу, и не накопилась ли задержка.
5. Убедитесь, что после возобновления нагрузка на CPU и канал вернулась к прежней, а не осталась повышенной.

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

Если вы меняли настройки качества ради испытания, запишите исходные значения перед началом и верните их после. Удобно вести короткую запись: что было, что стало, что вернули. Для самого сервера полезно заранее продумать сохранение конфигурации и данных: об этом подробнее написано в статье про бэкап и восстановление Owncast. Лучше сделать копию до экспериментов, чем восстанавливать настройки по памяти за час до эфира.

Протокол репетиции: что именно записать

Чтобы число вместимости не растворилось в воспоминаниях, ведите короткий протокол. По каждой ступени достаточно одной строки с полями: время начала и конца, число зрителей (имитированных и живых отдельно), настройки видео, максимум CPU, максимум исходящей скорости, замечания наблюдателей, показатели Stream Performance, если они доступны, и решение «ступень пройдена / не пройдена». Через неделю после репетиции вы будете благодарны себе за эту таблицу, особенно если придётся объяснять организаторам, почему вы просите уменьшить битрейт.

Какую вместимость вы можете записать в итоге

Результатом хорошей репетиции должно быть не расплывчатое «вроде держит», а конкретная формулировка в таком духе: «На выбранном тарифе при одном варианте качества с таким-то битрейтом и таким-то разрешением мы подтвердили устойчивую работу до N одновременных зрителей; предел определён каналом (или процессором); границу в M зрителей мы считаем рискованной; при резком старте безопасно N/2 в первую минуту». Подставьте свои числа, полученные испытанием, а не цифры из этой статьи: таблица выше была условной иллюстрацией расчёта, а не измерением.

Если подтверждённая вместимость ниже ожидаемого пика, у вас есть понятный набор рычагов: снизить битрейт, убрать лишний вариант качества, перенести часть аудитории на предстартовую страницу, взять тариф с большим числом ядер или другую локацию ближе к зрителям. Каждый рычаг можно проверить тем же ступенчатым опытом, и тогда в день мероприятия вы будете открывать эфир, зная свою цифру, а не надеясь на неё.