Size: a a a

1С, БСП, DevOps и Архитектура

2020 November 23

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
Елизавета Степанюк
Многоуважаемые коллеги. Есть сильная и внезапная проблема.
В конфигурации плотно используются http-сервисы крупного агрегатора. Может генериться несколько тысяч запросов к сервису за, допустим, 10 мин. Данные агрегратора используются и в самой 1с и во фронте (фронт это страничка html, в интернете).
С помощью этих данных делаем отчёты и кучу других операций. Изначально, во время имплементации API не было никаких ограничений на выборку, кроме ограничения количества записей в ответе. Именно по этому приходится генерить много запросов. Но сейчас ввели ещё и ограничения на максимум 4 запроса в секунду.
Соответственно пришлось резко проводить оптимизацию и костылить решения замедляющие наши запросы. Но так как работа через мою точку доступа ведётся весьма активно и из нескольких мест, то у запросов возникает конкуренция за время.
И сейчас некоторые запросы не проходят.
Как в идеале, с относительно минимальным количеством усилий, следует правильно решать эту проблему? Понятно что нужна очередь, и замедление запросов устраивать уже в этой очереди. Нужны приоритеты операций, некоторые запросы могут подождать, а некоторые нужно выполнить максимально быстро.
Может у кого-то есть какие-то более конкретные советы или может есть что почитать?
я правильно понимаю, что вы сами себя ограничиваете в 4 RPS?
источник

ЕС

Елизавета Степанюк... in 1С, БСП, DevOps и Архитектура
Nikita Gryzlov
я правильно понимаю, что вы сами себя ограничиваете в 4 RPS?
Это требование внешнего API, если больше 4 rps то возвращается код состояния 429, to many requests. И сейчас да, задача стоит замедлить себя для достижения этих самых 4 rps
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
Елизавета Степанюк
Это требование внешнего API, если больше 4 rps то возвращается код состояния 429, to many requests. И сейчас да, задача стоит замедлить себя для достижения этих самых 4 rps
ага, так и думал. вы можете попробовать ограничить RPS на стороне вашего веб-сервера. не знаю, как это делается для апача или IIS, но для nginx, например, есть вот такой модуль https://nginx.org/ru/docs/http/ngx_http_limit_req_module.html

ну или можно воткнуть nginx перед вашим веб-сервером.
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
очередь заданий, конечно, штука сама по себе полезная. но кажется, что проще смотреть в сторону tcp/http throughput
источник

VB

Vladimir Bondarevski... in 1С, БСП, DevOps и Архитектура
Елизавета Степанюк
Это требование внешнего API, если больше 4 rps то возвращается код состояния 429, to many requests. И сейчас да, задача стоит замедлить себя для достижения этих самых 4 rps
источник

VB

Vladimir Bondarevski... in 1С, БСП, DevOps и Архитектура
Умеет работать с кодами 429 и ждать
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
да, тоже хороший вариант!)
источник

ЕС

Елизавета Степанюк... in 1С, БСП, DevOps и Архитектура
о, это когда появилось? я уже юзаю коннектор, за что вам огромное спасибо) такой фичи вроде не было)) видимо пришло время обновиться)
источник

VB

Vladimir Bondarevski... in 1С, БСП, DevOps и Архитектура
Ну уже достаточно давно, но не с самого начала
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Что замедление, что ожидание не решает проблему. Убирают симптомы. Самое правильное делать очередь и распределять нагрузку.

Елизавета сервис вас ограничивает по ip или учётке?
источник

ЕС

Елизавета Степанюк... in 1С, БСП, DevOps и Архитектура
Oleg Tymko
Что замедление, что ожидание не решает проблему. Убирают симптомы. Самое правильное делать очередь и распределять нагрузку.

Елизавета сервис вас ограничивает по ip или учётке?
сервис рубит по учетке
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Елизавета Степанюк
сервис рубит по учетке
Ветис?
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
Oleg Tymko
Что замедление, что ожидание не решает проблему. Убирают симптомы. Самое правильное делать очередь и распределять нагрузку.

Елизавета сервис вас ограничивает по ip или учётке?
Нуууу, спорно. В микросервисной архитектуре и реактивщине tcp throughput применяется очень активно
источник

ЕС

Елизавета Степанюк... in 1С, БСП, DevOps и Архитектура
Oleg Tymko
Ветис?
это не так важно он сугубо корпоративный и не публичный
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Елизавета Степанюк
это не так важно он сугубо корпоративный и не публичный
Если ветис - там есть лазейки
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Nikita Gryzlov
Нуууу, спорно. В микросервисной архитектуре и реактивщине tcp throughput применяется очень активно
В итоге горлышко все равно будет на стороне 1с
источник

ЕС

Елизавета Степанюк... in 1С, БСП, DevOps и Архитектура
это агрегатор товарных позиций и остатков для федеральной сети
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
Oleg Tymko
В итоге горлышко все равно будет на стороне 1с
Горлышко в данном случае на стороне сервиса, у которого 4 rps. А 1с тут только как один из посредников обработки
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Елизавета Степанюк
это агрегатор товарных позиций и остатков для федеральной сети
Ещё вопрос. От части запросов можно избавиться кешированием?
источник

ЕС

Елизавета Степанюк... in 1С, БСП, DevOps и Архитектура
Nikita Gryzlov
Нуууу, спорно. В микросервисной архитектуре и реактивщине tcp throughput применяется очень активно
модуль nginx, который вы скинули вроде только на входящие ориентирован, или его можно как проксю повесить на порт, чтобы он ловил исходящие?
источник