Size: a a a

Scalability Camp — чат про распределенные системы (и про HPC)

2020 September 26

S

Slach in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
Подскажите какие есть пределв у poll подхода? Вот если есть гипотетическое приложение , которое каждые 3 секунды опрашивает сервер на наличие изменений. В какое ограничение физически оно упрется,если количество таких клиентов начнет расти
IMHO, архитектурно polling в лоб всегда хуже чем queue и/или push подходы

опрашиваем чаще чем появились изменения, больше паразитная нагрузка
могут быть криво посчитаны "изменения"
не успеваем вычитать изменения  в течении интервала поллинга

конкурентный поллинг

но иногда без polling по другому просто не получается реализовать

в общем да, без конкретики что именно вы полите и как контролируете ваш поллинг
(например с сервера контроль и тротлинг с клиента если fail)
сложно сказать
источник

S

Slach in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
Подскажите какие есть пределв у poll подхода? Вот если есть гипотетическое приложение , которое каждые 3 секунды опрашивает сервер на наличие изменений. В какое ограничение физически оно упрется,если количество таких клиентов начнет расти
но если отвечать на ваш запрос буквально

10 тысяч клиентов вам достаточно?
если да, то любая современная железка столько сетевых коннектов потянет
но если дальше за этим поллингом будет стоять что-то с СУБД
то все может лечь уже на 100 клиентах =)
источник

A

Alexander in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
Но это ведь треад блокируется и будет разбужен он как только произойдет одно из событий , которое ждём. Сам cpu ведь производства этом свободен. Будет допустим много тредов , каждый из который слушает события на своей тысячи сокетов через epoll_wait. Предел например в количестве таких активных именно соединений в секунду . Сколько запросов на обработку можно в секунду для того подхода обеспечить.
>В какое ограничение физически оно упрется
"Он", раз речь идёт о сервере, а не о приложении?
>Будет допустим много тредов , каждый из который слушает события на своей тысячи сокетов через epoll_wait.
Плодить на каждую тысячу сокетов по треду OS вряд ли имеет смысл
Рациональнее один тред с accept'ом, который ждёт подключения, далее перекидывает это вновь созданное соединение через round robin в другой epoll instance на другом треде, где и обрабатывается реакция на события. И суммарное число тредов вряд ли имеет смысл создавать больше чем число ядер(+1)
Для такой простой логики, как "раз в 3 секунды отдать что-то из памяти" такой подход может позволить обрабатывать десятки или сотни тысяч соединений
источник
2020 October 01

AB

Aleksandr Borgardt in Scalability Camp — чат про распределенные системы (и про HPC)
А mesos жив ?
источник

S

Slach in Scalability Camp — чат про распределенные системы (и про HPC)
Aleksandr Borgardt
А mesos жив ?
нет
также как и dc/os

все выглядит так что даже rancher2 не шибко то жив, хотя они бодрятся, но k3s из его состава вроде бы кто-то использует

рынок с моей колокольни выглядит как Managed Cloud K8S от всех ведущих провайдеров у которых под капотом все что угодно
и остальные там поверх своих виртуалок \ OpenShift \ bare metal сами что-то делают и всякие VMWare с этим как то помогают

но я могу быть сильно не прав, реальных цифр у меня нет
источник

S

Slach in Scalability Camp — чат про распределенные системы (и про HPC)
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Насколько помню, mesos используют иногда для standalone Spark'а, который надо держать без экосистемы Hadoop
источник
2020 October 05

MK

Murat Kasimov in Scalability Camp — чат про распределенные системы (и про HPC)
Всем привет! Думаю этот доклад подходит под тематику чата: https://www.youtube.com/watch?v=u7FD1kBzeb0&list=PLesLnxzG75m4Nn9ewiehV2Dep_qzDlTPN&index=1
источник

AB

Aleksandr Borgardt in Scalability Camp — чат про распределенные системы (и про HPC)
источник

ZO

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)
Этот чат создан именно для таких тем :)
источник

Constantine ʕ◔ϖ◔ʔ🦀... in Scalability Camp — чат про распределенные системы (и про HPC)
источник
2020 October 13

S

Slach in Scalability Camp — чат про распределенные системы (и про HPC)
@lynxed ;) кусь его
источник

ZO

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)
Slach
@lynxed ;) кусь его
Наползли )
источник

DM

Dilarang Merokok in Scalability Camp — чат про распределенные системы (и про HPC)
некоторые юзернеймы и картинки в профилях выглядят сгенерированными на скорую руку (и некоторые из них уже удалены).... интересненько...
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
господа, а в Авито до сих пор используют Saga или уже от них отказались?
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
кто-то, кажется, говорил, что они не осилили их поддерживать, но могу быть неправ
источник
2020 October 14

RS

Rinat Shigapov in Scalability Camp — чат про распределенные системы (и про HPC)
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Спасибо, гляну
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
кто-то, кажется, говорил, что они не осилили их поддерживать, но могу быть неправ
А на что перешли ?
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
А на что перешли ?
Вот и мне интересно
источник