я не понял, обычный стриминг же тестировать надо?

Ну издержки всюду есть

Ну если там чисто п2п то их по не нагружается от трансляции видео, нагружаются клиентский комп и комп оператора

ну супер, ничего грузить не надо - расходимся)

Насчёт пиринга - нужно у рутрекера спросить
Интересно, какие нагрузки

Вроде скачка торрент-файлов.. ии ?

Не знаю, есть ли ещё что-то :)

(Нагрузку на сам сайт не считаю, ЭТО ДРУГОЕ)

Камеры видеонаблюдения часто так работают

я тоже понятия не имею, но кажется будто если сервер с прилагой приляжет и p2p доступным быть перестанет, значит, вероятно, полезную нагрузку такими коннектами можно создать

я так понимаю что на плечах приложеньки может лежать маршрутизация, как минимум

либо оно может выступать проксей трафика

а теперь резко меняем тему)
@instaHipsta  а ты чтобы сокращать количество точек на графике делаешь:
|> window(...)
|> group()
или как то можно проще

Скажи, какие плюсы у перехода на flux

|> aggregateWindow(every: ${aggregation_interval}s, fn: sum)
Не подойдет?

Коллеги из PerformanceLab делают проект uxcrowd.ru. Там узкие места были
▫️в настройках nginx
▫️работе диска (видео - большие файлы, нагрузка на диск, нужны SSD, кеширование, ...)

Там не п2п, там экстеншен для хрома записывает видео (работает браузер клиента), посылает видосы на диск обычным http вроде

по степени важности:
1. ты снижаешь количество запросов к базе со стороны графаны. по сути в флюкс ты делаешь один большой запрос а потом с этой таблицей делаешь много операций чтобы получить любые варианты
2. шире встроенный функционал, по большому счету тебе не нужна вкладка Transformations в графане - ты можешь пилить любые джоины, группировки, превращать филды в строки и крутить как угодно табилчцы и графики. ты можешь делать любые операции над тэгами (включая ВРЕМЯ!), сортировать группировать вычитать и складывать, даже конвертация типов есть.
3. ты можешь выбирать агрегационные интервалы, как выше Степа кинул
4. ты можешь работать с несколькими датасорсами внутри 1 запроса
5. ты можешь управлять временем и удобно с ним взаимодействовать, встроенный таймшифт, или фильтровать данные по диапазону часов (без перевода в таймстемпы) ( |> hourSelection(start: 9, stop: 17))
6. встроенный функционал ковариации (не связано с коварностью) - это по сути поиск линейной зависимости, довольно классная штука
7. работает с геоданными, умеет дергать широту долготу всякое такое

в целом работает быстрее, движок другой

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

звучит интересно