В материале рассмотрены причины снижения скорости работы Адаптера СМЭВ, изучен вариант переустановки Адаптера для повышения его производительности и описано собственное решение команды Хемуль IT для ускорения работы ПО Минкомсвязи — «Бустер Адаптера СМЭВ».
Проблема снижения скорости работы Адаптера СМЭВ
Те участники межведомственного взаимодействия, кто достаточно интенсивно обмениваются сообщениями со СМЭВ через Адаптер, по прошествии некоторого времени обнаруживают прискорбный факт. Со временем сообщения отправляются в СМЭВ медленнее, чем в начале эксплуатации Адаптера, а очередь ответов или входящих запросов разбирается не так быстро, как ожидалось.
Встроенный пользовательский интерфейс Адаптера (GUI) также либо начинает реагировать с большой задержкой, либо перестает открываться вовсе.
Этот эффект «деградации» производительности Адаптера обусловлен тем, что все сообщения Адаптер сохраняет в собственной базе данных, и по мере увеличения количества записей в таблицах увеличивается и время выполнения SQL-запросов к этим таблицам.
«Отработанные» записи (записи, относящиеся к сообщениям, по которым завершен цикл документооборота, т.е. на исходящий запрос получен ответ, а на входящий запрос отправлен ответ) не удаляются Адаптером из базы, а накапливаются и со временем приводят к описанным выше результатам.
Варианты решения
Самый быстрый, простой и неправильный способ решить проблему – установить новый инстанс Адаптера с чистой базой. При этом теряется связь между запросами, отправленными в предыдущем инстансе, и ответами, полученными в новом инстансе, которую теоретически можно восстановить вручную SQL-запросами через консоль H2.
Более правильным, сложным и системным решением является очистка базы H2.
Командой Хемуль IT разработана утилита для корректной очистки базы данных от «отработанных» записей – «Бустер Адаптера СМЭВ». Утилита написана на Java и представляет собой самодостаточный (содержащий JDBC-драйвер H2) jar-архив, запускаемый из командной строки.
Утилита очищает как основную рабочую схему CORE БД Адаптера, так и схему UI, используемую во встроенном пользовательском интерфейсе. Необходимость очистки схемы UI определяется параметром в конфигурационном файле.
В конфигурационном файле можно также задать «глубину» очистки в минутах. Будут удаляться отработанные записи, связанные с запросами, отправленными не позже, чем текущее время минус глубина очистки. Это сделано для того, чтобы информационная система участника взаимодействия могла обработать полученные за это время ответы (отправить ответы на полученные запросы).
Кроме того, в параметрах командной строки можно указать конкретную дату, до 00:00 которой все отработанные записи будут удалены. В этом случае глубина очистки, определенная в конфигурационном файле, игнорируется.
При удалении записей из базы H2 можно наблюдать увеличение размера файла с данными. Это происходит из-за того, что удаленные записи сохраняются в журнале транзакций (про организацию файла БД H2 можно почитать здесь). И хотя при этом скорость выполнения запросов и производительность Адаптера возрастает, но «пухлый» файл может вызывать беспокойство сисадминов, зорко контролирующих наличие свободного места на серверных дисках и создающих резервные копии баз данных.
Для решения этой проблемы утилита может (при установке соответствующего параметра в конфигурационном файле) при завершении работы выполнять команду “SHUTDOWN DEFRAG”, которая в разы уменьшает размер файла с данными. Перед запуском утилиты с параметром DEFRAG необходимо остановить Адаптер, потому что после завершения работы утилиты соединение с базой будет потеряно для всех ее клиентов.
В ближайшем релизе утилиты планируется реализовать копирование отработанных записей в архивную базу данных перед их удалением (текущая версия их просто удаляет). Функционал следующих релизов будет зависеть, в числе прочего, от комментариев к этой статье, а также от опыта использования текущего релиза.
По вопросам приобретения решения «Бустер Адаптера СМЭВ» свяжитесь с командой Хемуль IT любым удобным для Вас способом.
Можно написать за неделю свой адаптер на базе библиотек того же Восхода.
Мы написали свой адаптер, который благополучно справляется со средним потоком запросов по СМЭВ около миллиона в месяц (в основном по ПФР и ЕГИССО, включая запросы с вложениями через файловое хранилище СМЭВ), при этом все цепочки запросов хранятся в базе Oracle и никакого проседания производительности не наблюдается даже при отключенной мультиочередности доступа к видам сведений.