Допустим, есть некий бот, он делает polling, тебе удобно его использовать в разработке, он периодически запрашивает новые активности с телеграм-сервера. На какие метрики стоит смотреть не со стороны пользователя, а со стороны запущенного бота? Можно смотреть на количество открытых соединений, утилизацию ресурсов, ошибки, профилировать узкие места на основе метрик. А есть ли какие-то готовые решения, которые могут помочь с оценкой производительности работы бота (как с точки зрения утилизации ресурсов сервера, так и с точки зрения общей нагрузки от всех пользователей)? Стоит ли вообще переходить от polling модели, если текущий вариант потенциально может выдержать прогнозируемый рост?
И еще интересно, на основе каких показателей можно принимать решение о масштабировании бота.
склоняюсь к тому, что маршрут хранится на конечных узлах сообщения, т.е. у конечных пользователей.
Логично предположить, что так и есть. Иначе какие преимущества от использования DHT. Хотя вариант с хранением на корневых узлах тоже имеет место быть. Надо поизучать.
Если смотреть в общих чертах, при значительном увеличении количества узлов в сети, компромисс будет пока что не в пользу скорости передачи данных. То есть технология пока что может быть хорошо применена в аварийных ситуациях (про маски-шоу описано выше) и в качестве резервного канала.
Напоминает описание работы протокола динамической маршрутизации в сетях TCP/IP, в частности OSPF. Только там, вроде как, используется высший адрес среди интерфейсов.
Когда в сети появляется участник с более подходящим ключом, дерево координат перестраивается, считая его корнем.
Если, теоретически, будет большой рост узлов в сети, то это скажется на производительности. В штатном режиме работы корень может вычисляться, допустим, один раз на тысячу (зависит от размера пространства координат, как я понимаю). Но если принять во внимание, что устройства могут быть недоступны и нужно довольно быстро эту недоступность заметить, то такие перестроения могут здорово повысить сетевые задержки.
Модель угрозы заключается в импульсообразном появлении и исчезновении узла с ключом подписи, который вынуждает остальных участников перестраивать координаты, беря его за точку отсчета.
А какие-нибудь способы защиты от этого имеются?
В отличие от первого запроса, установленная сессия между двумя участниками в большинстве случае осуществляется по одному маршруту, основанному на координатах транзитных узлов.
То есть, получается, каким-то образом строится таблица маршрутизации узлов и где-то хранится. Если каждый узел теоретически может выступать в роли маршрутизатора, то где должны храниться записи построенного маршрута?
Еще каким-то образом нужно понимать доступность узла в сети. В протоколах динамической маршрутизации периодически ходят healthchecks. А как это реализовано для узлов мэш-сети?
null может обозначать разные вещи в разных контекстах
Мне наиболее близка интерпретация вида null - это null. То есть, значение отсутствует. По умолчанию/перепутано — выглядит как антипаттерн, можно просто избегать этого при сериализации данных.
Это здорово, что производится попытка продумать возможные ошибки, но перенос логики на уровень транспорта вносит излишнюю сложность.
Паттерн has помогает проверить наличие значения для непримитивных типов. Для примитивных можно обходиться значением по умолчанию. Да, бывают случаи, когда сложно отличить значение по умолчанию от его отсутствия. Но это, опять же, зависит от получателя данных и на его стороне было бы проще это решать.
1) Чем были замотивированы исполнители и руководители? Деньги, безвыходность, использовались ли какие-то рычаги давления?
2) Почему социальная проблема решается техническими средствами? Есть ли обратная связь к Мэрии? Почему не выдвинули очевидные проблемы (селфи в 4 утра, геопозиция, перегрев батареи, сложности регистрации), с которыми можно столкнуться при эксплуатации решения?
3) Планируете ли в дальнейшем послушно исполнять указания, не думая о последствиях?
4) Планируете ли в дальнейшем делать подобного рода решения, которые усложняют людям жизнь?
5) Стали бы пользоваться сами данным решением?
6) Насколько я понял, кучу штрафов получили именно те люди, которые этого меньше всего заслуживают (врачи после контактов с зараженными). Я уверен, что они добросовестно выполняли свою работу, за это им отплатили штрафами. Возможно, штрафы отменят (по крайней мере, в правовом государстве это должно быть так), но осадок никуда не исчезает. Планируется ли отменить все штрафы и признаться во вредительстве?
7) Если до этого ДИТ разрабатывал решения, которыми можно было пользоваться опционально, то здесь это носило другой характер. Будем честны, решение оказалось вредительским. О ДИТ узнали больше лиц. Как вы считаете, дурной пиар тоже полезен для компании?
8) Разработка подобного рода решения говорит о нулевом уровне доверия к граждана со стороны мэрии. В свою очередь, последствия данного решения приводят к снижению доверия со стороны гражданам. Получается замкнутый цикл (который всегда существовал). Как считаете, как можно выйти из данного цикла? Какой вклад вы и ваши подчиненные могут внести в это?
9) Считаете ли вы, что цель оправдывает средства?
Если какие-то вопросы кажутся не относящимися непосредственно к решению, мне видится это по-другому. Я просто не могу понять мировоззрение, при котором можно делать подобное, не думать о последствиях и не признаваться в допущенных ошибках. Данное поведение видится мне рациональным для ответственного человека только в случае, если вопрос касается физического выживания (вопрос #1).
Спасибо, хорошо написано.
Небольшая ремарка. Вот на этой картинке https://habrastorage.org/r/w1560/getpro/habr/upload_files/5f4/81e/21c/5f481e21c932d0fcfab39e56977455c8.png варианты 3 и 4 полностью идентичны. Наверное, для варианта 4 имелось в виду: y=1 x=1 b=x a=y.
Наверное, имелось в виду Clojure.
Допустим, есть некий бот, он делает polling, тебе удобно его использовать в разработке, он периодически запрашивает новые активности с телеграм-сервера. На какие метрики стоит смотреть не со стороны пользователя, а со стороны запущенного бота? Можно смотреть на количество открытых соединений, утилизацию ресурсов, ошибки, профилировать узкие места на основе метрик. А есть ли какие-то готовые решения, которые могут помочь с оценкой производительности работы бота (как с точки зрения утилизации ресурсов сервера, так и с точки зрения общей нагрузки от всех пользователей)? Стоит ли вообще переходить от polling модели, если текущий вариант потенциально может выдержать прогнозируемый рост?
И еще интересно, на основе каких показателей можно принимать решение о масштабировании бота.
Логично предположить, что так и есть. Иначе какие преимущества от использования DHT. Хотя вариант с хранением на корневых узлах тоже имеет место быть. Надо поизучать.
Если смотреть в общих чертах, при значительном увеличении количества узлов в сети, компромисс будет пока что не в пользу скорости передачи данных. То есть технология пока что может быть хорошо применена в аварийных ситуациях (про маски-шоу описано выше) и в качестве резервного канала.
Напоминает описание работы протокола динамической маршрутизации в сетях TCP/IP, в частности OSPF. Только там, вроде как, используется высший адрес среди интерфейсов.
Если, теоретически, будет большой рост узлов в сети, то это скажется на производительности. В штатном режиме работы корень может вычисляться, допустим, один раз на тысячу (зависит от размера пространства координат, как я понимаю). Но если принять во внимание, что устройства могут быть недоступны и нужно довольно быстро эту недоступность заметить, то такие перестроения могут здорово повысить сетевые задержки.
А какие-нибудь способы защиты от этого имеются?
То есть, получается, каким-то образом строится таблица маршрутизации узлов и где-то хранится. Если каждый узел теоретически может выступать в роли маршрутизатора, то где должны храниться записи построенного маршрута?
Еще каким-то образом нужно понимать доступность узла в сети. В протоколах динамической маршрутизации периодически ходят healthchecks. А как это реализовано для узлов мэш-сети?
Пожалуй, соглашусь с предыдущим комментарием.
Мне наиболее близка интерпретация вида
null - это null. То есть, значение отсутствует. По умолчанию/перепутано — выглядит как антипаттерн, можно просто избегать этого при сериализации данных.Это здорово, что производится попытка продумать возможные ошибки, но перенос логики на уровень транспорта вносит излишнюю сложность.
Паттерн has помогает проверить наличие значения для непримитивных типов. Для примитивных можно обходиться значением по умолчанию. Да, бывают случаи, когда сложно отличить значение по умолчанию от его отсутствия. Но это, опять же, зависит от получателя данных и на его стороне было бы проще это решать.
1) Чем были замотивированы исполнители и руководители? Деньги, безвыходность, использовались ли какие-то рычаги давления?
2) Почему социальная проблема решается техническими средствами? Есть ли обратная связь к Мэрии? Почему не выдвинули очевидные проблемы (селфи в 4 утра, геопозиция, перегрев батареи, сложности регистрации), с которыми можно столкнуться при эксплуатации решения?
3) Планируете ли в дальнейшем послушно исполнять указания, не думая о последствиях?
4) Планируете ли в дальнейшем делать подобного рода решения, которые усложняют людям жизнь?
5) Стали бы пользоваться сами данным решением?
6) Насколько я понял, кучу штрафов получили именно те люди, которые этого меньше всего заслуживают (врачи после контактов с зараженными). Я уверен, что они добросовестно выполняли свою работу, за это им отплатили штрафами. Возможно, штрафы отменят (по крайней мере, в правовом государстве это должно быть так), но осадок никуда не исчезает. Планируется ли отменить все штрафы и признаться во вредительстве?
7) Если до этого ДИТ разрабатывал решения, которыми можно было пользоваться опционально, то здесь это носило другой характер. Будем честны, решение оказалось вредительским. О ДИТ узнали больше лиц. Как вы считаете, дурной пиар тоже полезен для компании?
8) Разработка подобного рода решения говорит о нулевом уровне доверия к граждана со стороны мэрии. В свою очередь, последствия данного решения приводят к снижению доверия со стороны гражданам. Получается замкнутый цикл (который всегда существовал). Как считаете, как можно выйти из данного цикла? Какой вклад вы и ваши подчиненные могут внести в это?
9) Считаете ли вы, что цель оправдывает средства?
Если какие-то вопросы кажутся не относящимися непосредственно к решению, мне видится это по-другому. Я просто не могу понять мировоззрение, при котором можно делать подобное, не думать о последствиях и не признаваться в допущенных ошибках. Данное поведение видится мне рациональным для ответственного человека только в случае, если вопрос касается физического выживания (вопрос #1).