Меня зовут Алексей Доильницын, я архитектор в DINS. Наша компания участвует в разработке высоконагруженной UCaaS-платформы (Unified Communication as a Service).
Я работаю в команде, которая отвечает за разработку сервиса видеоконференций. Видеоконференции с большим количеством участников в галерее часто бывают неподъемными для устаревших лэптопов. Мы решили эту проблему с помощью теории систем автоматического управления (САУ).
Видеоконференции стали особенно актуальными в начале 2020 года в связи с массовым переходом на работу из дома. Тогда же мы столкнулись с интересной проблемой: некоторые пользователи жаловались на постоянный гул вентиляторов, на быстрое расходование батареи и «торможение» устройства. Оказалось, что конференции с большим количеством участников в галерее бывают неподъемными для устаревших лэптопов, которые часто встречаются дома. И мы стали эту проблему решать — с помощью теории систем автоматического управления.
Задача и подход к решению
Сервис выпускает нативного клиента для основных платформ Mac и Windows. Клиент построен на Electron (библиотека для разработки настольных приложений с использованием HTML), что существенно экономит ресурсы разработки, так как по сути позволяет разработать только одно веб-приложение на JavaScript, которое актуально сразу для трех основных платформ — веб, Mac и Windows.
По нашему опыту, двухъядерные процессоры Intel старше 5 лет уже зачастую не справляются с типичными корпоративными конференциями с 8-16 участниками.
4-х ядерные современные Core i5 — это, наверное, минимальная конфигурация для подобных задач. У более слабых компьютеров возникают проблемы вроде высокого расхода батареи и «подвисания» компьютера.
Для решения этой задачи я решил воспользоваться теорией систем автоматического управления (САУ). Ее обычно используют для решения таких задач, как стабилизация танковой башни или поддержание постоянной температуры в плавильной печи. САУ обеспечивают надежность и устойчивость управления.
Вместо того, чтобы заставлять пользователя выбирать ключевые параметры системы (разрешение и количество видео потоков, битрейт и т.п.), программная система может сама адаптироваться к внешним условиям (загрузка ЦПУ (CPU), пропускная способность сети), автоматически выбирая наиболее оптимальные параметры.
Построение системы управления
Система управления функционирует в JavaScript коде клиента видеоконференции.
Объектом управления в нашем случае являются видеопотоки, рисуемые на экране пользователя. На загрузку ЦПУ в первую очередь влияют количество потоков и разрешение видео (высота х ширина).
9 видеопотоков в разрешении 640x360:
В качестве обратной связи выбираем системную загрузку ЦПУ. Поскольку в браузере нет соответствующего API, измеряем загрузку ЦПУ в нативном коде (в плагине Electron) и периодически шлем событие с текущей загрузкой ЦПУ в JavaScript код.
Выбираем целевой коридор загрузки ЦПУ, например, 40-50%.
В качестве ошибки используем разницу между текущей загрузкой ЦПУ и ближайшей границей коридора. Например, текущая загрузка 80%, значит ошибка 80-50=30 в абсолютных величинах, или по отношению к коридору: 30/50=0.6 (60%).
Основная логика системы управления проста. Система срабатывает на прилетающие информационные события, в которых передается текущая загрузка ЦПУ. События приходят с достаточно большим интервалом в 10 секунд, чтобы учесть инерцию системы на отработку управляющих воздействий.
Если загрузка ЦПУ выше целевого коридора, то сначала уменьшаем разрешение потоков, потом начинаем выключать потоки.
Если загрузка ЦПУ ниже целевого коридора, то сначала включаем выключенные потоки, потом увеличиваем их разрешение.
Если загрузка внутри коридора, то ничего не делаем — во избежание колебаний.
При этом количество потоков, на которые будет оказано воздействие, рассчитывается из величины ошибки. Например, клиент отрисовывает 16 видеопотоков в среднем разрешении 640х360. Если загрузка ЦПУ 80% и соответственно ошибка равна 0.6, то за один шаг мы уменьшим разрешение для 16*0.6=10 потоков. Это делается для того, чтобы система быстрее реагировала на большие возмущения. При этом мы учитываем, что отрисовка одного потока занимает от долей до единиц процентов полной загрузки системы.
Проблемы, возникшие в результате эксплуатации
Внутри коридора
В процессе тестирования нам встретилась ситуация, когда система, находясь внутри коридора, получает внешнее возмущение в виде антивируса, который существенно повышает загрузку ЦПУ на некоторое время. Так как наша система управления не различает внешние и внутренние воздействия, она штатно реагирует на повышение загрузки отключением видео потоков. После завершения работы антивируса система возвращается обратно в коридор, но уже с отключенными видео потоками. Находясь в коридоре, система ничего не предпринимает, дабы избежать незатухающих колебаний. Для пользователя такое поведение выглядит странно.
Решение: все-таки включать видео потоки внутри коридора, но медленно, например, по одному потоку на каждый третий вызов.
Мощный компьютер
На мощном компьютере обработка потока видео занимает доли процента от общей загрузки ЦПУ, и отключать видео потоки бессмысленно, так как они практически не влияют на загрузку системы.
Решение: измерять, сколько ЦПУ потребляет наш процесс в процентах от общего потребления системы. Если доля нашего процесса менее 50%, то отключать систему управления.
Финальный тест
В финальном тесте на старом лаптопе с процессором i5-3210M (4 cores @ 3 GHz) участвовали 8 участников (ботов) в разрешении 320х180. Стартовая загрузка ЦПУ около 80%.
Через 30 секунд отключается четыре участника, загрузка опускается до 65%.
Ниже опускаться уже некуда, так как минимальное количество участников на экране — 4.
В итоге система прошла тесты и успешно используется.
Если у вас появились какие-то вопросы или хотелось бы узнать что-то еще об RCV — пишите в комментариях.
