Мы продолжаем разбирать варианты нагрузочных тестов. В этой статье мы разберем методику тестирования и проведем нагрузочный тест, с помощью которого попытаемся определить число пользователей, которые одновременно будут и зрителями, и стримерами, т.е. каждый пользователь и публикует, и просматривает потоки.
Эта статья продолжает цикл статей о нагрузочных тестах нашего сервера. Мы уже рассмотрели, как собирать метрики, как на основе этих метрик подбирать оборудование и сравнили способы тестирования. Сегодня посмотрим, как ведет себя сервер при работе с микшированием потоков.
В прошлой статье мы провели нагрузочное тестирование, по результатам которого можно было подбирать сервер под нагрузку. В этих тестах, мы публиковали на одном WCS поток, который потом забирали энное количество раз при помощи второго WCS, и, на основе полученных результатов, делали выводы о работособности железа.
Кто-то может справедливо усомниться в непредвзятости такого теста. Ведь получается, что мы тестируем свой сервер при помощи второго своего сервера. Может быть у нас там есть какой-то специально оптимизированный код, благодаря которому мы улучшаем показатели теста в свою пользу.
В любом проекте большое внимание уделяется подбору серверного оборудования и WebRTC стриминг не исключение. При подборе сервера один из главных принципов --- достичь баланса, чтобы и оборудование в пустую не работало и качество контента от несостоятельности железа не страдало. Итак, как же все таки выбрать правильный сервер?
Системы мониторинга — очень нужная для админа вещь, ведь они позволяют получать от сервисов метрики, которые:
Когда мы пишем статьи о своем сервере в комментариях очень часто находится читатель, который говорит:
"И зачем такой огород городить? Все это одной FFmpeg командой делается!"
В этой статье поднимем несколько надоевшую тему вебинаров и инструментов для их проведения. Нет. Писать систему для проведения вебинара не будем. Их уже до нас написано превеликое множество. Обсудим возможность подключить к вебинару рисовалку, чтобы можно было делать пометки от руки и транслировать все это дело в поток.
Несколько недель назад мы выкатили статью про Докер и WebRTC сервер и рассказали в ней о нюансах запуска. Читатели справедливо усомнились в пригодности докера для продакшена по следующим причинам:
Кнопка "Click to Call" на сайте — это "инновация", которой уже около 10 лет. Технологии под капотом изменились, а принцип остался прежним - кликаем по кнопке на странице сайта, запускается JavaScript, который запрашивает доступ к микрофону и устанавливает соединение с сервером — WebRTC SIP шлюзом. Далее одна клиент-серверная нога — это браузер-шлюз, вторая нога может быть сколь угодно длинной и через цепочку SIP proxy может соединяться в конечном счете с мобильным или стационарным телефоном. Таким образом, браузер превращается, в каком-то смысле, в софтфон и становится полноправным участником VoIP телефонии.
Популярность онлайн-образования увеличивается с каждым месяцем. А где увеличение популярности, там и возрастание конкуренции и улучшение качества: многие авторы онлайн-школ поняли, что уже мало снимать какую-то кашу из пикселей на фронталку четвертого айфона - нужно работать над качеством картинки, звука, подачей материала и т.д. Мало того, что пандемия доказала, что онлайн можно преподавать хоть сальсу, хоть вязание крючком, так это еще и дало очень большой толчок к улучшению преподаваемых материалов + разнообразие на рынке труда. Мамочки в декрете могут ликовать - теперь действительно можно зарабатывать сто тысяч миллионов в секунду, сидя дома.
Во время карантина, который то ослабевает, то активизируется с удвоенной силой, появилось огромное множество новых профессий. Сторисмейкеры, инфопродюсеры, специалисты по запускам инфопродуктов и прочие неведомые звери - все они освоили новую работу, которая смогла прокормить их в пандемию. Нанимаете сторисмейкера, который прошел какие-то курсы (дай бог, нормальные, а не от инфоцыган) - он пилит за вас вовлекающие истории в Инстаграм и ваш курс продается. С контентмейкерами та же история - просто нанимаете такого человека, он вам и шапку профиля везде оформит, и на каком-нибудь Геткурсе уроки упорядочит, и статьи напишет, которые тоже помогут в продвижении курсов. Полный полет фантазии: если вам кажется, что какой-то профессии не существует, значит вы просто мало сидите в интернете. В принципе онлайн-работа популяризировалась и теперь уже вряд ли кто-то скажет: "Да он фигней какой-то занимается - ТикТоки свои снимает, а лучше бы на заводе вкалывал!".
Перед разработчиком или владельцем программного продукта часто возникает вопрос выбора подходящего места для размещения серверных мощностей. Как известно, софт не может быть без харда.
В предыдущей статье, мы вспомнили, что такое WebRTC CDN, как эта технология помогает обеспечивать минимальную задержку в WebRTC трансляциях и почему для CDN не лишним будет использовать балансировку нагрузки и автоматическое масштабирование.
Современные браузеры не предоставляют возможность выбора - использовать WebRTC или не использовать. И если проиграть поток можно по HLS, MSE, то захватить поток с камеры и публиковать поток из браузера можно только с помощью WebRTC. Производители браузеров приняли этот "формат" и внедрили его в свои продукты. Так же как в свое время, те же вендоры поддерживали Flash Player в качестве плагина. Текущая ситуация с WebRTC отличается только тем, что WebRTC встроен в браузер нативно, на уровне кода, а не в виде плагина. Если через пару лет кто-то предложит лучшую библиотеку для работы с видео, нет сомнений, что вендоры перейдут на эту новую технологию. Но сегодня в мире браузеров правит бал Chrome, поэтому горизонт для WebRTC остается чистым.
Подавляющее большинство IT специалистов разных направлений стремится как можно меньше действий выполнять руками. Не побоюсь громких слов - то что может быть автоматизировано, должно быть автоматизировано!
Представим ситуацию: нужно разворачивать много однотипных серверов, причем делать это быстро. Быстро разворачивать, быстро сворачивать. Например, разворачивать тестовые стенды для разработчиков. Когда разработка ведётся параллельно нужно разделить разработчиков, что бы они не мешали друг-другу и возможные ошибки одного из них не блокировали работу остальных.
Путей решения этой задачи может быть несколько:
Как известно, у YouTube отсутствует фича захвата RTSP потока, и мы постараемся заполнить этот пробел - помочь YouTube осчастливить пользователей.
Алиса — опытный фулл-стек разработчик и способна за неделю написать каркас SAAS проекта на своем любимом фреймворке с использованием php. На фронтенде предпочитает Vue.js.
В телеграмм стучится заказчик, которому во что бы то ни стало надо разработать веб-сайт, который будет местом встречи работодателя и сотрудника для проведения очного интервью. Очного — означает глаза в глаза, прямого видео контакта в реальном времени с видео и голосом.
«Почему не скайп?» — спросите вы. Так уж повелось, что серьезные проекты, а каждый стартап, несомненно, себя таковым считает, стараются предложить внутренний сервис коммуникаций по самым разным причинам, среди которых:
Виртуальная реальность нынче на пике моды. Оборудование, что во времена "Газонокосильщика" было уделом сумасшедших ученых гиков с большими деньгами от Минобороны, сейчас и простому человеку по карману, а те, у кого карман совсем пуст, могут собрать VR-гарнитуру из картона и смартфона по множеству рецептов.
Егор закрыл крышку ноутбука и потер красные от недосыпа глаза. "Клиенты продолжают жаловаться на зависания стрима, новый пакет исправлений совсем не помог! Что же делать с этим (censored) HLS?" — произнес он в пустоту кабинета.
Существует две основных функции работы WebRTC на стороне сервера в области потокового видео: публикация и воспроизведение. В случае публикации видеопоток захватывается с вебкамеры и двигается от браузера к серверу. В случае воспроизведения, поток двигается в обратном направлении — от сервера к браузеру, декодируется и воспроизводится в браузерном HTML5 <video> элементе на экране устройства.
