Поправить API set_block_applied_callback.

[asuleymanov]

Предлагаю исправить данну API функцию, а именно: 1) На данный момент там по идее можно выбрать тип передаваемых данных. Выбор из 4 пунктов (block, header, virtual_ops, full). На самом деле данный параметр никак поменять нельзя, т.е. от задается жестко как block https://github.com/golos-blockchain/golos/blob/4facdb3f7d671de63ef0f258c21f7eb16466ee2f/plugins/database_api/api.cpp#L198. Предлагаю убрать все варианты кроме full. Чтобы в ответе были все операции. 2) Предлагаю стандартизировать ответ по данной операции. А именно: Возвращать структуру : block_num - номер блока op_count - колличество операций в блоке vop_count - колличество виртуальных операций в блоке []Array Operations - непосредственно сам масив со всеми операциями как обычными так и виртуальными.

В этом случае при использовании данного API очень сильно можно снизить нагрузгу на API ноду. Клиентам просто не прийдеться посылать зарос каждые 3 секунды для получения данных.

[asuleymanov]

Вообще я туту за ночь хорошо подумал и есть такое предложение. Пункт номер 2 не нужен в полной реализации, а именно не надо иметь параметры op_count и vop_count. Кому надо и так посчитает какие операции есть в блоке. А вот пункт 1 желательно реализовать(с включением оставшегося запрос по пункту 2. А именно номер блока и массива операций.) Уже давно это обсуждалось и вроде как решилось (https://golos.id/ru--golos/@vik/preimushestva-novogo-websocket-api-golosa-podpiska-setblockappliedcallback-teper-soderzhit-tranzakcii) но что то пошло не так. Система на данный момент возвращает только виртуальные операции. Кстати в статье не завуалированно приведен плюс для API нод с использованием данного подхода.

[t3ran13]

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

Например запросы можно закешировать для http и снять нагрузку с ноды, а вот если по вебсокетам на ноду подпишется слишком много слушателей это может ее убить, один из вариантов для абуза.

было бы неплохо иметь возможность отключать подписку по вебсокетам. (хотя можно с плеча вообще порт вебсокетов закрыть конечно)

[asuleymanov]

Ну ладно если ноду не жалко и денег много давайте параметр на отключение подписок еще введем.

А вот убрать в websocket вообще супер идея. Хороший арбуз по нагрузке на ноду сделаем.

[t3ran13]

Человек из леса, почитайте про кэширование запросов или кэширующие прокси, например varnish. Да что угодно, по на эту тему море)

Вообще снижать нагрузку на серваки вводя кэширующие слои общемировая практика

[asuleymanov]

Нда как обычно/ Ничего кроме конкретики написать кроме оскорблений.

Что такое кешированние и для чего оно нужно я знаю. Но вот скажите мне пожалуйста как Ваше хваленое кеширование спасет от массового запроса на broadcast операции?

[t3ran13]

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

И да, сам метод уменьшает число запросов к серверу, но серверу приходится поддерживать соединение, и при том у соединения не настраивается время жизни, т.е. после реконекта соединение все равно живет в памяти ноды и обрабатывается время Х. Это лучше чем запрос/ответ без кеша, но хуже чем с кешем. Все данные поподаемые в ноду после ласт иверсибл блок статичны ( до тоже статичны но могут быть переписаны, подписка через вебсокеты тоже не решает этой проблемы), и самое логичное их хранить в кэше, а не каждый раз нодам переваривать и достовать данные из блоклога.

Зы Ты сам задал тон беседе, поумничал и мимо

[t3ran13]

Ну и насколько я помню стату от коре, нода не держала больше 400 запросов. С кешем это легче.

В идеале конечно вообще graphql еще бы, кто-то даже делал, но это уже другая история

[asuleymanov]

В том-то и решение этой операции. Уменьшается количество запросов на году для получения данных. Она просто сама эти данные в момент приёма рассылает.

[t3ran13]

Еще раз, как ты сам сказал, что нода занимается рассылкой данных, это тоже нагрузка на ноду.

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

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

Пока блок лог у голоса небошой и это не так критично как для стима, но вопрос времени когда и мы откажемся от вебсокетов и перейдем на кешь и хттп

[asuleymanov]

Зы Ты сам задал тон беседе, поумничал и мимо

В данном issue разговор не поро сравнение http и websocket. И уж тем-более не про какой из этих протоколов оставить, а какой убрать.

Я не говорил про отключение websocket. Это ты сюда влез с этим. Так что поро поумничать это к тебе.

[t3ran13]

В данном ишью я попросил сделать параметр для отключения подписок через конфиг, с аргументами, я понял что тебе это не нужно, но нужно мне.

[asuleymanov]

При чем операция все равно есть но работает криво. По идее должна присылать блок без виртуальных операций по умолчанию, а присылает как раз только виртуальные операции. При чем параметр который отвечает на тип данных задан жестко. Я предлагаю сделать как задумывалось. А именно без всяких параметров чтобы система выдавала блок со всеми операциями как виртуальными так и обычными. Вот и все. По идее это сделать просто сменив параметр в строке https://github.com/golos-blockchain/golos/blob/4facdb3f7d671de63ef0f258c21f7eb16466ee2f/plugins/database_api/api.cpp#L198 на значение full.

[asuleymanov]

В данном ишью я попросил сделать параметр для отключения подписок через конфиг, с аргументами, я понял что тебе это не нужно, но нужно мне.

Ну возможно ты и прав и стоит сделать такой параметр для ноды. Но думаю стоит разделить это. Т.е. сделать еще issue для данного параметра. Не стоит усложнять. Как раз легче разбить на мелкие и что будет легче то реализуют быстрее.

[isteric-senior]

Так вот же берется из аргумента ниже: https://github.com/golos-blockchain/golos/blob/4facdb3f7d671de63ef0f258c21f7eb16466ee2f/plugins/database_api/api.cpp#L201 Но только если он указан верно.

[asuleymanov]

Так вот же берется из аргумента ниже: https://github.com/golos-blockchain/golos/blob/4facdb3f7d671de63ef0f258c21f7eb16466ee2f/plugins/database_api/api.cpp#L201

Но только если он указан верно.

Если не затруднит можете показать как передать данный параметр. Просто я понимаю так что я передаю id который потом используется как опознавательный знак для прослушивателя.

[isteric-senior]

@asuleymanov правильный пример вызова есть тут: https://github.com/GolosChain/golos/pull/945

[asuleymanov]

К сожалению не удаллось даже запустить тот пример что прислали. В нем ошибки