This article continues the series of articles on load tests. Today we will analyze the testing methodology and answer the question: "How many IP cameras can be connected to a WebRTC server?"

Эта статья продолжает цикл статей по нагрузочным тестам. Сегодня мы разберем методику тестирования и ответим на вопрос "Сколько IP камер можно подключить к WebRTC серверу?"

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

Do you remember how just a few years ago it was a disaster to lose a camera at the end of a vacation? All memorable pictures and videos then disappeared along with the lost device. Probably, this fact prompted the great minds to invent cloud storage, so that the safety of records no longer depends on the presence of the devices on which these records are made.

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

We continue to review variants of load tests. In this article we will go over the testing methodology and conduct a load test that we will use to try and determine the number of users that could watch and stream at the same time, meaning the users will simultaneously publish and view the streams.

This article is a continuation of our series of write-ups about load tests for our server. We have already discussed how to compile metrics and how to use them to choose the equipment, and we also provided an overview of various load testing methods. Today we shall look at how the server handles stream mixing.

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

В прошлой статье мы провели нагрузочное тестирование, по результатам которого можно было подбирать сервер под нагрузку. В этих тестах, мы публиковали на одном WCS поток, который потом забирали энное количество раз при помощи второго WCS, и, на основе полученных результатов, делали выводы о работособности железа.

Кто-то может справедливо усомниться в непредвзятости такого теста. Ведь получается, что мы тестируем свой сервер при помощи второго своего сервера. Может быть у нас там есть какой-то специально оптимизированный код, благодаря которому мы улучшаем показатели теста в свою пользу.

In the previous article we went over a load test whose data could be used to choose a load-appropriate server. In the course of the testing, we would publish a stream on one WCS, and we would pick up that stream several times using a second WCS. The acquired results could be used as a basis for decisions on server operability.

Some would (justly) have concerns regarding the possible biases in such a test — after all, one of our servers was used to test another one of our servers. Could it be that we were using a specially optimized code that skewed the results in our favor?

In any project, a great deal of importance is placed on the selection of server hardware and WebRTC streaming is no exception. One of the key principles of such a selection is balance – the hardware should be powerful enough to handle the streams with no drops in quality, but not too powerful so as to waste resources. So, how does one choose the right server?

В любом проекте большое внимание уделяется подбору серверного оборудования и WebRTC стриминг не исключение. При подборе сервера один из главных принципов --- достичь баланса, чтобы и оборудование в пустую не работало и качество контента от несостоятельности железа не страдало. Итак, как же все таки выбрать правильный сервер?

Monitoring systems are a vital tool for any system administrator, because they can be used to extract specific information from services, such that:

Системы мониторинга — очень нужная для админа вещь, ведь они позволяют получать от сервисов метрики, которые:

In the comment sections of our articles about our server there are often users who say: "Why would you jump through so many hoops, when you can do the same with a single line of code in FFmpeg!?"

Когда мы пишем статьи о своем сервере в комментариях очень часто находится читатель, который говорит:

"И зачем такой огород городить? Все это одной FFmpeg командой делается!"

В этой статье поднимем несколько надоевшую тему вебинаров и инструментов для их проведения. Нет. Писать систему для проведения вебинара не будем. Их уже до нас написано превеликое множество. Обсудим возможность подключить к вебинару рисовалку, чтобы можно было делать пометки от руки и транслировать все это дело в поток.

In this article we will once again return to the tired topic of webinars and webinar hosting tools. And no, we're not about to code a whole new system for webinar hosting – there are already plenty of those. Instead, we will talk about connecting drawing software to the webinar, so that you could manually draw and broadcast the process.

Несколько недель назад мы выкатили статью про Докер и WebRTC сервер и рассказали в ней о нюансах запуска. Читатели справедливо усомнились в пригодности докера для продакшена по следующим причинам:

A few weeks ago we wrote an article about Docker and WebRTC servers and talked about the intricacies of launching containers. Our readers (rightly) questioned whether Docker was a suitable tool for production, for the following reasons: