Войти

Настройка интенсивности обмена ИУА со СМЭВ

В процессе использования ИУА участники взаимодействия могут столкнуться с необходимостью повышения скорости обмена сообщениями со СМЭВ3. Следует понимать, что скорость обмена ограничивается, прежде всего, со стороны СМЭВ3, подробнее об этих ограничениях Вы можете прочитать в документе Методические рекомендации СМЭВ 3. Однако, в зависимости от ресурсов хоста на котором развернут и работает ИУА, могут существовать сценарии повышения скорости обмена, достижимые путем изменения его настроек.
ИУА поставляется с набором настроек по умолчанию, которые являются оптимальными для большинства сценариев обмена, поэтому с осторожностью изменяйте настройки, поскольку необдуманные действия могут спровоцировать снижение скорости работы. В каждом конкретном случае использования ИУА в обменах, оптимизированные настройки будут отличаться.

Вот основные факторы, приводящие к таким различиям:

  • Средний размер сообщения
  • Способ передачи вложений (при их использовании)
  • Количество используемых информационных систем
  • Общий объем переданных сообщений
  • Глубина и периодичность архивации данных
  • Вычислительные ресурсы

По этой причине статья не содержит универсальных описаний оптимизации. Цель статьи – предоставление администратору достаточной информации о происходящих в ИУА процессах и влиянии настроек на них.

 

Базовые настройки ИУА

Зайдите в панель администрирования ИУА и ознакомьтесь со следующими параметрами, способными оказать влияние на скорость обменов:

image1.png

  • 5.1. Задержка перед началом приёма сообщений (время в миллисекундах)

Определяет время простоя после старта ИУА, по истечении которого будет начат обмен со СМЭВ и через внутренние интерфейсы адаптера. Технологический параметр, изменять который не рекомендуется.

  • 5.2. Периодичность приёма сообщений (время в миллисекундах)

Периодичность генерации команд на прием сообщений от СМЭВ. В рамках запуска каждого сеанса приема сообщений может генерироваться несколько команд, в зависимости от настроек многопоточности.

image2.png

  • 9.1. Коэффициент увеличения скорости опроса

В ИУА встроен механизм, позволяющий кратно увеличить количество сообщений из СМЭВ, получаемых в рамках одного сеанса обмена. Признак необходимости увеличения количества принимаемых сообщений устанавливается в настройках каждой информационной системы индивидуально.

При переключении параметра информационной системы [5.1 Режим получения сообщений] с «NORMAL» на «MAX», на указанный здесь коэффициент умножается [4.2 Количество забираемых из СМЭВ сообщений]. Т.е. ИУА начинает принимать из СМЭВ большее количество сообщений в рамках одного сеанса получения.

image3.png

  • 13.1 Максимальное число потоков

Количество потоков, обрабатывающих входящие сообщения из СМЭВ в каждом поде (для ИУА Enterprise). Параметр оказывает виляние как на количество потоков обмена ИУА со СМЭВ, так и на количество потоков во внутренних интерфейсах ИУА, предназначенных для обмена с ИС участника взаимодействия (напр. AMQP).

 

Настройки информационных систем

Рассмотрим индивидуальные настройки информационных систем, влияющие на производительность обменов:

image4.png

  • 4.1. Количество сообщений, забираемых из СМЭВ

Ограничение максимального количества сообщений, забираемых из СМЭВ в рамках одного потока и сеанса обмена.

Важно: При слишком большом количестве забираемых сообщений есть риск, что их получение займет времени больше, чем задано в настройках Kafka (для ИУА Enterprise), это приведет к ресурсоемкой операции по ребалансировке, что в конечном итоге снизит общую скорость получения. Для single-версии ИУА так же имеется опасность замедления обмена в случаях, когда запущенный сеанс обмена не успевает получить указанное количество сообщений до запуска следующего сеанса.
  • 4.2. Количество параллельных запросов в нормальном режиме

Количество команд (потоков) на получение сообщений, генерируемых в режиме получения сообщений «NORMAL».

Пример: при значении 10 в рамках одной сессии в СМЭВ будет отправлено 10 GetRequest (команд на получение запросов) и 10 GetResponse (команд на получение ответов). Действует суммарно на все поды http-adapter.

  • 4.3. Количество параллельных запросов в режиме нагрузки

Количество команд на прием сообщений, генерируемых в режиме получения сообщений «MAX» для одного пода http-adapter.Пример: при значении 10 в рамках одной сессии в СМЭВ будет отправлено 10 GetRequest и 10 GetResponse.

image5.png

  • 5.1. Режим получения сообщений

«Normal» –нормальный режим, «MAX» -режим нагрузки. При переключении [5.1 Режим получения сообщений] с «NORMAL» на «MAX», на указанное в [9.1. Коэффициент увеличения скорости опроса] значение умножается [4.2 Количество забираемых из СМЭВ сообщений]. Т.е. ИУА начинает принимать из СМЭВ большее количество сообщений в рамках одного сеанса получения. Так же меняется количество параллельных запросов с [4.2. Количество параллельных запросов в нормальном режиме] на [4.3. Количество параллельных запросов в режиме нагрузки].

Параметр предназначен для случаев, когда в ИУА создано несколько информационных систем и некоторые из них требуется периодически переключать в отличный от стандартного режим приема сообщений. В случае, если в ИУА создана одна информационная система или все информационные системы должны работать в равнозначном режиме, не рекомендуем изменять значение этого параметра. Помните, что при его изменении ИУА лишь переключается на использование других полей настроек, никаких дополнительных изменений алгоритмов обработки сообщений не происходит. В то же время, использование различных режимов может запутать вас и усложнить анализ поведения ИУА. В абсолютном большинстве случаев для достижения результата достаточно оперирования цифровыми значениями параметров, использующихся в нормальном режиме работы информационной системы.

 

Схема взаимодействия микросервисов ИУА при получении сообщений из СМЭВ

Теперь, когда вы понимаете суть настроек, ознакомьтесь со схемой взаимодействия микросервисов Enterprise-версии ИУА:

image6.png

Если вы применяете Single-версию ИУА, помните, что от Enterprise- версии она отличается отсутствием сервиса Apache Kafka, а также невозможностью горизонтального масштабирования, поэтому для нее схема будет выглядеть следующим образом:

image7.png

Взаимосвязь параметров конфигурации ИУА

С указанной в [5.2. Периодичность приёма сообщений] периодичностью, для каждой настроенной информационной системы генерируются команды на получение сообщений из СМЭВ в количестве [4.2. Количество параллельных запросов в нормальном режиме] шт.

Время, за которое ИУА получит от СМЭВ количество сообщений, заданное в [4.1. Количество сообщений, забираемых из СМЭВ] должно быть менее таймаута, установленного в Kafka (для Enterprise-версии ИУА). В случае, если сообщения не были получены до таймаута, происходит ресурсоемкая операция по ребалансировке, что в конечном итоге приведет к снижению производительности процесса получения сообщений из СМЭВ. Так же, получение заданного количества сообщений должно быть окончено до запуска очередного сеанса получения.

Количество партиций в Kafka (для Enterprise-версии ИУА) должно быть не менее количества порождаемых за один цикл генерации команд, а также быть не менее суммарного количества листнеров на всех подах (количество подов http-адаптера, умноженное на настройку многопоточности [13.1]).

 

Советы по настройке параметров ИУА

Исходя из приведенных схем и описания взаимосвязи параметров конфигурации, выделим несколько правил, соблюдая которые вы повысите вероятность достижения прироста производительности путем корректировки настроек ИУА:

  • Параметр [13.1 Максимальное число потоков] в сумме должен быть не меньше суммы значений параметров [4.2. Количество параллельных запросов в нормальном режиме] всех информационных систем, умноженной на два. Учитывайте это, изменяя связанные параметры или добавляя новые информационные системы.
  • Если вы наблюдаете неравномерность скорости поступления сообщений, возможно это связано с тем, что ИУА не успевает получать пакет сообщений до запуска очередного сеанса обмена. Уменьшите [4.1. Количество сообщений, забираемых из СМЭВ] или увеличьте значение параметра [5.2. Периодичность приёма сообщений].
 

Деградация производительности ИУА при большом объеме хранимых сообщений

В процессе работы ИУА, данные о переданных и принятых сообщениях сохраняются в служебных таблицах базы данных. По мере возрастания количества хранимых сообщений, происходит постепенная деградация производительности БД, приводящая к увеличению времени обработки сообщений. Для решения этой проблемы ИУА имеет механизм архивации сообщений, в процессе которого старые сообщения, а также сообщения, взаимодействие по которым успешно закончено, переносятся из БД в файловое хранилище.

Параметры работы механизма архивации доступны в панели администрирования после нажатия кнопки Показать расширенные настройки:

image8.png

По умолчанию, через 14 суток (336 часов) после создания в архив переносятся сообщения, взаимодействие по которым не закончено, а сообщения с завершенным процессом взаимодействия переносятся в архив через 24 часа (86400 сек.) после завершения взаимодействия.

Данные значения настроек оптимальны в большинстве случаев. Рекомендуется изменять их в сторону уменьшения только в случаях аномального повышения нагрузки (количества отправляемых/принимаемых сообщений) в течение последних суток.

Периодичность запуска процесса архивации определяется значением пункта настроек [14.3 Периодичность архивации] в следующем формате:

image9.png

По умолчанию процесс архивации запускается ежесуточно в полночь.
Корректность работы службы архивации можно проверить по записям лог-файла. Процесс начинается записью вида:

INFO r.r.s.a.u.b.s.RsArchivingService - process archive start

И заканчивается записью вида:

INFO r.r.s.a.u.b.s.RsArchivingService - process processArchiveScheduler end

Помните, что после удаления (переноса в архив) значительного количества записей БД PostgreSQL, для достижения наибольшего эффекта требуется запуск процедуры освобождения неиспользуемого пространства командой VACUUM. Обратитесь к документации используемой вами БД для изучения подробностей.

Авторизуйтесь, чтобы оставить комментарий к статье